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