20:00:19 #startmeeting Ansible Windows Working Group 20:00:19 Meeting started Tue Oct 9 20:00:19 2018 UTC. 20:00:19 This meeting is logged and archived in a public location. 20:00:19 The chair is jborean93. Information about MeetBot at http://wiki.debian.org/MeetBot. 20:00:19 Useful Commands: #action #agreed #halp #info #idea #link #topic. 20:00:19 The meeting name has been set to 'ansible_windows_working_group' 20:02:29 * gundalow waves 20:02:35 howdy 20:02:42 * bcoca waves 20:02:45 will give it a few minutes 20:02:51 o/ 20:02:55 Nothing from me, just lurking 20:03:14 #chair dag 20:03:14 Current chairs: dag jborean93 20:03:42 While we wait, is anyone going to Linux.conf.au? I know this is a Windows working group, but some of you do work for RedHat. 20:04:02 #chair mcassaniti 20:04:02 Current chairs: dag jborean93 mcassaniti 20:04:08 hey welcome mcassaniti 20:04:17 I'm not going to that 20:04:58 Thank you. Pity you're not going. It would be nice to talk to a few people working with similar technologies. 20:05:18 are you in NZ? 20:05:50 No I'm in NSW, AU. You're still in Brisbane? 20:06:00 yep, haven't changed from there 20:07:33 Looks like it's just us 3 today, nitzmahone is currently flying high through the sky 20:08:25 let's get through what we can 20:08:38 #topic https://github.com/ansible/community/issues/294#issuecomment-426854715 win_hosts module 20:09:03 someone has submitted a module to manage the Windows host file 20:09:27 I'm wondering whether this is actually needed considering you can easily use win_lineinfile to achieve what you want 20:10:12 jborean93: not necessarily, since you may want to manage 2 ip addresses for 1 name, or 2 names for 1 ip address 20:10:31 jborean93: so it's a bit more complex than just line-based management 20:10:42 how is that different? You would put the line in accordingly 20:10:57 adding or removing an alias isn't that simple 20:10:57 What do people currently do in *NIX considering there's no module there? 20:11:18 dag: forgive my ignorance, what's not simple about it? 20:11:22 mcassaniti: same there, I think there's an advantage to have it there as well 20:12:00 jborean93: you want to add 192.168.1.2 with name jordan 20:12:15 and 192.168.1.2 with jordan.borean.org already exists 20:13:05 so either you have to know this in advance (which is a problem in itself) or you replace that line, which gets rid of what was there 20:13:08 just add a new line with `192.168.1.2 jordan` 20:13:15 that works on Windows 20:13:58 that's a poor man's implementation, because it could be already in that file 20:14:13 if you use win_lineinfile then that shouldn't be an issue 20:14:14 so if you have a green field that may work as well 20:14:26 How about going in the other direction. Is there are reason not to approve, and what technical debt or risk is carried keeping it. 20:14:35 it would be a problem with win_lineinfile 20:15:04 mcassaniti: mostly around maintenance 20:15:14 dag: how? 20:15:29 if you already have "192.168.1.2 jordan.borean.org jordan" in that file, you're basically adding it twice 20:16:13 regex can solve that, on the other hand people would need to know that so I kind of get the point 20:16:30 it makes it very complex 20:16:31 I just see this becoming a complex module for people trying to handle all these edge cases 20:16:59 e.g. removing a line with multiple aliases but not removing it properly 20:17:28 if you consider the hosts file a relational database, a module knowing the 'object model' and providing all operations makes sense 20:17:55 I've seen some crazy hosts files before 20:18:03 and the hosts file is a very simple format, so I don't expect a lot of problems once it's finished (incl. tests) 20:19:21 ok, as long as there are thorough tests I will be fine with it 20:24:09 I'll post a comment on the PR saying just that 20:24:20 next in line 20:24:27 #topic https://github.com/ansible/community/issues/294#issuecomment-426865988 win_reboot validation 20:24:45 not sure if you wanted to wait for nitzmahone dag, he probably would have some thoughts on this 20:25:02 yes 20:25:18 I prefer jhawkesworth is present as well 20:25:27 no worries, will skip that for this meeting 20:25:30 the more the merrier =) 20:25:45 same for the next topic, actually 20:26:04 yea, sorry mcassaniti for dragging you in was hoping more people would be here 20:26:16 was there anything you wanted to discuss about the win_updates PR while we are here 20:26:31 It's not a problem. At least I get to see what goes on. 20:26:59 after doing retries for WinRM and PSRP I think we need to add this framework to fetch_url and open_url too (we should handle temporary HTTP errors better everywhere) 20:27:14 I was planning on just making category_names a free form choice 20:27:29 But not sure on the performance implications of not filtering any updates during the initial searcher 20:27:57 dag: I need to set aside some time to look at that PR 20:28:06 jborean93: Nothing stands out at present. I do think it wise to move to filtering all categories at the end, but that also potentially makes for a change in module behaviour. 20:28:08 I haven't really been able to get to it yet 20:28:49 mcassaniti: yep, I personally think we can change that behaviour but not willing to make that statement without Matt's approval 20:29:18 if we do the post filtering we get the added benefit of being able to see all updates that are available and what has been filtered 20:29:35 I did note that win_updates is marked preview. Happy to wait for Matt. Thanks for the feedback on win_snmp btw. 20:29:59 cool, gives us some leeway :) 20:30:13 no worries, will try and keep an eye out when it's ready for review again 20:31:38 since last meeting there's also a new win_partition module 20:32:00 It doesn't look like chopraaa is here, will have to try and review it at some point 20:34:03 What else do you have? 20:34:14 that's the end of the list really 20:34:21 #topic open floor 20:34:51 Would you like me to join again next week assuming nitzmahone is here? 20:35:23 we would love for you to join whenever you can, I know AUS timezones are a bit hard but with DST it hopefully isn't too early for you 20:35:47 Do we already have a view on the v2.8 Windows roadmap ? 20:36:13 It could be worse. I'll see what I can do. 20:36:46 I need to talk to Matt on that, has been a list of things I've been working on but nothing solidified unfortunately 20:37:07 I can do something quick, my flights just about to board 20:37:24 if Australia is becoming even more popular in our WG, we may have to move the meeting to accommodate for the majority ;-) 20:38:21 quick ! 20:39:02 nitzmahone: was mostly looking at https://github.com/ansible/ansible/pull/45708 20:39:21 should we remove the pre filtering of the updates, get all available and filter based on the human name 20:39:44 there are other categories that don't have a documented GUID so this allows us to be more dynamic and return info on updates that have been skipped 20:40:01 otherwise the PR as it stands has a `post_category_names` which filters post search 20:40:17 Generally not opposed to that, only downside is that misspelled category names are silently ignored 20:40:33 yep, at least the output will show them now 20:41:01 Is there any performance implications? 20:41:04 I'd rather have one or the other 20:41:30 Hmm, the worst case to test would be like an out of the box 2008R2 or something. 20:41:45 I was wondering whether we would hit the json limit on that 20:41:54 I can definitely test it out 20:41:56 I don't know how smart the server side filtering is 20:42:12 I'm guessing "not very", so probably negligible impact 20:42:27 nitzmahone: The current categories are in CamelCase, but moving to full post category searching will break this. The module is preview. Will this be an issue? 20:42:27 it takes forever on a new box anyway to get updates for just 1 category 20:42:42 mcassaniti: we should have a translation for those 20:42:56 But the other case to test there would be fresh out of box with only one category applied to see if future scans are ridiculously slower than with server filtering 20:43:44 Would we want to have strict matching on the category names, or allow a regex match like we do on the whitelist/backlist 20:43:44 (so apply one category, then do the scan again and see if it's significantly slower with client filtering than with server filtering) 20:44:14 I could see either way, if someone's really lazy just do *, but God help you 20:44:33 it's more `Security` would match `Security Updates` or `Windows Security` or something like that 20:44:39 it uses `-match` 20:44:43 Hrm, not sure on that one 20:45:06 Seems like a new category could end up being accidentally applied 20:45:07 I'm fine having a strict match, as long as we still return the updates that were filtered out 20:45:17 Though I guess any wildcard could potentially do that 20:45:27 +1 20:45:33 so people can see why this wasn't part of the updates to install 20:45:53 Only other thing there is that that list could potentially be quite large 20:46:18 Do we want to always return it or only in a diagnostic mode or logger or something 20:46:46 well we currently return `filtered_updates` in the whitelist/blacklist scenario 20:47:55 That's also a much smaller set of users (I'm guessing) 20:48:27 Switching it to the main category filter might just be really noisy, but I don't imagine it actually causing problems 20:48:29 yep, I find it useful for state: searched as it let's me know all the updates that are available and how I can filter it down 20:48:54 so if someone wants to find out valid category names 20:48:57 * nitzmahone mumbles maybe we need win_updates_facts or some such 20:49:15 we could do that as well 20:49:28 We could also keep a known list and warn on misses (or like you say, just do strict matching still) 20:49:29 s/as well/instead/ 20:49:45 They don't add new categories often, but it does happen 20:50:00 I just know how painful it is to find category names, they really aren't documented well 20:50:40 What about new products? Any new product name would need to be added to the known list. 20:50:50 I can't remember, are we returning the full update dict in filtered or just the KBID? 20:50:57 full 20:51:10 so it shows the title, kb, categories (since this PR), and guid 20:51:38 and I recently added filtered_reason in the PR to state why it was filtered 20:52:00 Well, +1 for consistency there I guess 20:52:31 ok, sounds like we should look at the performance between pre and post filtering against a fresh old box 20:53:01 if there is little to no difference we can filter out the updates after the search 20:53:08 Yep.. Boarding now (they're late), TTYL 20:53:17 no worries, have a good flight 20:54:21 mcassaniti: do you have the ability to measure the performance on a fresh 2008 R2 box? 20:54:33 I certainly do. 20:55:03 Who's making the code changes? 20:55:10 that would be great if you can test that out and give some feedback, if you need any help feel free to reach out 20:55:31 You can :) but let's see the performance impact 20:55:47 I can make the changes next week. 20:55:48 you can probably just create a cutdown PS script that you run locally for testing purposes at first 20:55:58 but I'll leave that up to you 20:56:55 anything else we wish to discuss? 20:58:57 going once 20:59:05 twice 20:59:09 three times.... 20:59:16 closed 20:59:19 #end meeting 20:59:23 #endmeeting