20:00:08 <jborean93> #startmeeting Ansible Windows Working Group
20:00:08 <zodbot> Meeting started Tue Jun 26 20:00:08 2018 UTC.
20:00:08 <zodbot> This meeting is logged and archived in a public location.
20:00:08 <zodbot> The chair is jborean93. Information about MeetBot at http://wiki.debian.org/MeetBot.
20:00:08 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
20:00:08 <zodbot> The meeting name has been set to 'ansible_windows_working_group'
20:00:12 <jhawkesworth_> hey
20:00:33 <jborean93> hey
20:00:39 <jborean93> #chair jhawkesworth_
20:00:39 <zodbot> Current chairs: jborean93 jhawkesworth_
20:01:28 <nitzmahone> o/
20:01:33 <jhawkesworth_> hey
20:01:52 <jborean93> #chair nitzmahone
20:01:52 <zodbot> Current chairs: jborean93 jhawkesworth_ nitzmahone
20:02:28 <jborean93> seems to be just us 3 for today unless someone else joins
20:02:56 <jborean93> I've added a few topics for the agenda today after browsing the GH issues last week
20:03:08 * jhawkesworth_ looks
20:03:39 <jborean93> #topic https://github.com/ansible/community/issues/294#issuecomment-399319602
20:04:10 <jborean93> There is a PR to add support for specifying an alternative URL for sourcing the Chocolatey install script
20:04:16 <jhawkesworth_> I think its easy enough to install chocolately locally if you need it
20:04:31 <jhawkesworth_> win_copy or win_get_url if you have a local webserver
20:04:58 <jhawkesworth_> I don't use chocolatey much but reluctant to add more to the module
20:05:04 <jborean93> those are my thoughts, this should really be something done outside the module and I am loath to add more complexity to win_chocolatey as it is
20:05:23 <jborean93> On the other hand, it is really convenient that it installs it's own dependencies but really isn't correct
20:05:46 <jhawkesworth_> I have no objection to having an example in the docs of installing choco.exe from local source
20:06:43 <jhawkesworth_> there was some chat on Friday here last week where I think consensus was that a chocolatey_sources module would be the right thing to do, but neither dag or myself use it, so we weren't volunteering
20:06:51 <jhawkesworth_> (slight aside)
20:07:01 <jborean93> yea that's something we should look at at some point
20:07:45 <jhawkesworth_> its perhaps not obvious to go looking for a chocolatey_sources module unless you happen to be familar with linux package management
20:08:12 <jhawkesworth_> perhaps a an ansible chocolatey guide could   solve that though
20:08:36 <jborean93> I would say just linking it from chocolatey would probably be enough for now
20:09:06 <jhawkesworth_> fair enough
20:09:14 <jhawkesworth_> see if it starts causing user questions first
20:09:52 <jborean93> cool
20:09:53 <nitzmahone> Yeah, if anything, I'd rather just add something to the module that says "don't try to install"
20:11:11 <jhawkesworth_> in the case where they try to specify chocolatey as the thing to install?
20:12:24 <jborean93> this is more for when choco.exe is not present and win_chocolatey automatically downloads and installs from a public URL
20:12:31 <jhawkesworth_> sort of wish the magic install hadn't happened but can't take it away now
20:12:38 <jborean93> yea same here
20:13:04 * nitzmahone has mixed feelings
20:13:16 <nitzmahone> It's "neat", but definitely a source of problems.
20:14:14 <jborean93> the question remains do we want to add another param like `install_source` to allow specifying a different URL for the choco install.ps1 script
20:15:15 <jhawkesworth_> I'd rather have an example of installing it using `win_get_url` in the documentation than another module parameter
20:15:41 <jborean93> my feelings are the same, would also confuse people when they source `source` and `install_source`
20:16:59 <nitzmahone> Agreed- we shouldn't add an alt source for the script (but maybe a way to just make it not try to install at all if user wants to handle by some other method)
20:17:24 <jhawkesworth_> I guess we could deprecate the silent install in favour of installation examples.
20:17:38 <jborean93> that would be up to them installing it before calling win_chocolatey
20:18:03 <nitzmahone> Silent install is nice demoware
20:18:04 <jhawkesworth_> yeah that way they are in control of what version they have installed
20:18:24 <jborean93> sounds good will update the issue and say thanks but now thanks. Add an example instead
20:18:33 <jborean93> #topic https://github.com/ansible/community/issues/294#issuecomment-399325575
20:19:08 <jborean93> Currently win_regedit does not support keys with `/` in the name. The PS registry provider automatically converts that to a key/path separator
20:19:21 <nitzmahone> I'd probably suggest using templated win_regmerge or something
20:19:34 <jhawkesworth_> yeah that's annoying but its powershell trying to be helpful
20:19:41 <jhawkesworth_> this exact thing has come up before
20:19:44 <nitzmahone> Damn SCHANNEL keys
20:19:48 <jborean93> win_regmerge is not idempotent, plus the .reg file is pretty strict in how it needs to be formatted IIRC
20:19:51 <nitzmahone> Whoever named those things needs a 2x4 to the head
20:20:13 <jhawkesworth_> this guy fixed using win_shell:
20:20:14 <jhawkesworth_> https://github.com/deekayen/ansible-role-schannel/blob/master/tasks/windows/ciphers.yml
20:20:45 <jhawkesworth_> L70
20:20:48 <jborean93> yea you can get it working but the registry module Ansible uses just won't support it
20:21:03 <jborean93> or it will create a subkey which wouldn't be the intended behaviour
20:21:15 <nitzmahone> I talked it over a couple times with the Powershell PMs, they were kinda like, "yeah that sucks, but we're probably not going to fix it"
20:21:40 <jborean93> you can use .net to create it
20:21:59 <jborean93> the issue with us doing that is it could break compatibility with someone who already uses `/` as a path separator
20:22:33 <nitzmahone> Yeah; maybe a "literal_path" or some kind of flag that says "don't try to munge this"
20:22:36 <jborean93> the only saving grace is that you can't do a path like `HKLM:/SOFTWARE/path/to/key`, the root must be `HKLM:\`
20:23:07 <jborean93> so `HKLM:\SOFTARE/path/to/key` currently works and would break in that scenario
20:24:15 <jhawkesworth_> I like `literal_path` idea best I think
20:24:33 <jborean93> hmm that could be tricky and complex in the module code
20:24:39 <nitzmahone> Anything "automatic" we do here is going to break somebody
20:24:52 <jborean93> would have to swap between .net and PS based on that flag
20:25:07 <nitzmahone> Which is why I dropped it last time it came up ;)
20:25:28 <jhawkesworth_> yeah is baggage to carry for 1% of uses otherwise
20:25:54 <nitzmahone> Tell SCHANNEL team to stop giving their keys names that can't be managed in Powershell
20:25:56 <jhawkesworth_> `win_registry_dotnet` module perhaps?
20:26:00 <jborean93> I personally think that someone who did `HKLM:\SOFTARE/path/to/key` would be rare
20:26:35 <nitzmahone> Yeah, but it's even been in the docs in the past that you can use forward slashes in most cases
20:26:48 <jborean93> really?
20:26:57 <jhawkesworth_> I can just imagine someone storing a unix path under a certain point in the registry
20:27:13 <jborean93> but you need to use the backslash for the HKLM:\ part
20:27:15 <nitzmahone> Given the problems in the past with that, there are almost certainly playbooks out there doing it with K=V syntax or people passing on cmdline or whatever
20:27:20 <jhawkesworth_> not sure if it was in the docs but was in my first fest talk I think
20:27:27 <jborean93> so why would someone use \ at the start and then swap to /
20:27:41 <nitzmahone> It's not been in the docs for that module, but the Windows docs in general in the past have mentioned it
20:27:52 <nitzmahone> Lack of escaping
20:28:01 <nitzmahone> (laziness)
20:28:14 <nitzmahone> I'm not saying we *shouldn't* break them, just saying I'm sure they're out there
20:28:32 <jhawkesworth_> I have seen apps which basically have a 'home' registry location ... and then dump all manner of crap in subkeys
20:28:49 <jborean93> ok my vote was to break that and put it in the porting guide for that scenario but if you disagree that's fine
20:28:52 <jhawkesworth_> I'm afraid they are out there
20:29:06 <nitzmahone> Yep. Also constructed subkeys via vars- could be HKLM:\{{stuff}} in the playbook but the var has /
20:29:16 <nitzmahone> I don't necessarily disagree
20:29:24 <jborean93> nitzmahone true I didn't think of that scenario
20:29:26 <nitzmahone> Just saying they *are* out there
20:30:11 <nitzmahone> Question is: do we just hard-break it, or try to do a deprecation cycle?
20:30:44 <nitzmahone> The latter seems to imply a flag, which gets us into either dual impl or replicating the munging powershell does in the provider ourselves
20:31:03 <nitzmahone> (neither of which are palatable to me personally)
20:31:03 <jborean93> we can probably detect if `/` is used in the path after the provider and throw a dep warning. Trouble is that it seems like once the key is there it would actually work right now
20:31:09 <jborean93> it's just creating that key where it would fail
20:31:24 <jborean93> yea the dual implementation is not something I want to go down
20:31:29 <jborean93> the module is complex enough as it is
20:32:26 <nitzmahone> `/` *should* be a pretty corner case; we could just toss it in the porting guide I suppose
20:32:46 <jhawkesworth_> yes I vote for that.
20:32:56 <jhawkesworth_> you can workaround as we have seen
20:34:16 <nitzmahone> Still a lot of work to basically completely expunge the Powershell providers...
20:34:31 <nitzmahone> Well, *some* work
20:34:40 <jborean93> we already use .net for setting properties IIRC
20:34:49 <jborean93> it's more the key side where we still use PS
20:35:22 * jhawkesworth_ is trying not to get annoyed.  Its stuff like this that makes powershell still feel like a toy
20:35:46 <nitzmahone> Meh- just a nasty corner case intersection of two features
20:36:07 <jborean93> jhawkesworth_ maybe if Windows never used `\` as a path separator and based it on `/`
20:36:14 <jborean93> would solve so many issues
20:36:41 <jhawkesworth_> yeah very true
20:36:48 <jborean93> ok so we are ok with changing the functionality of `/` to mean the actual key name and not a path sep + porting guide info
20:38:26 * jhawkesworth_ grepping playbooks
20:38:34 <jborean93> we can probably check if `\` is used at all in the path. If not replace `/` with `\` and throw a dep warning saying to specify `\` as a path separator and it will be removed in future versions
20:39:06 <jborean93> the only scenario that would break is if you wanted a root key to have `/` in the name
20:39:29 <jhawkesworth_> which sounds like it would be pretty rare
20:40:31 <nitzmahone> Yep
20:40:36 <jhawkesworth_> I can live with that
20:40:46 <jhawkesworth_> esp as I have 0 examples in my playbooks
20:41:36 <jborean93> cool will update the agenda item with how we want to move forward in that
20:41:55 <jborean93> last one on the agenda from me
20:41:57 <jborean93> # https://github.com/ansible/community/issues/294#issuecomment-399328025
20:42:01 <jborean93> #topic https://github.com/ansible/community/issues/294#issuecomment-399328025
20:42:55 <jborean93> basically the `creates_version` is only comparing the major.minor.build part of a file version
20:43:07 <jborean93> If a file has .something_else it is ignored
20:43:24 <jhawkesworth_> its a bit fiddly but how about having a `creates_version_full` alternative to `creates_version` on win_package
20:43:35 <jhawkesworth_> then you could use either
20:44:07 <jborean93> that's one option
20:44:10 <jhawkesworth_> as long as docs are clear that full version is exact, creates version ignores the private part
20:44:18 <jhawkesworth_> nobodys playbooks get broken
20:44:25 <jborean93> could also have another option that specifies what version to compare it with
20:44:49 <nitzmahone> I think I'd prefer the latter
20:44:50 <jhawkesworth_> yeah that could work
20:44:50 <jborean93> e.g. has options like `major, minor, build, raw` and allows something to specify the version based on that
20:45:05 <jborean93> wording up for debate :)
20:45:07 <nitzmahone> Oh, I thought you meant which property
20:45:31 <nitzmahone> Basically default works as it does today, but you can override to compare a different property version
20:45:33 <jhawkesworth_> yeah iirc there are typically a bunch of properties in the registry's uninstall stuff
20:45:58 <jborean93> there's also that, the trouble with going with the property is that someone would need to know the names of properties. Simple enough to give an example for people to use though
20:46:19 <jhawkesworth_> that would be quite good as there's sod all consistency about what uninstall properties get populated in my experience
20:46:50 <nitzmahone> This is also arguably a very minor corner case
20:47:01 <jhawkesworth_> indeed
20:47:19 <jborean93> yep cool, so add extra option to specify the version property to compare it with
20:47:33 <jhawkesworth_> for folks who don't want to look in the registry and used product_id, I think this version appears in the installed programs list
20:47:39 <nitzmahone> Typical end-users aren't installing different patch versions of the same major/minor/build; this is almost certainly a CI case or something
20:48:19 <nitzmahone> We can specify a valid list of values as well (if it's what I'm thinking)
20:48:53 <jborean93> do we want the list of values to be word for word based on the Version properties or Ansiblised naming?
20:49:22 <nitzmahone> Given how rarely it's likely to be used, I'd just go for the raw PS prop names
20:49:41 <jborean93> cool, keeps things simmple
20:51:07 <jhawkesworth_> yep happy with that
20:51:31 <jborean93> sounds good to me
20:51:34 <jborean93> #topic open floor
20:51:36 <jhawkesworth_> if you need to be really specific, you'll have to go for a dive into the registry anyway
20:52:18 <jhawkesworth_> I'm contemplating `win_active_hours` module for later windows so you can set active hours.
20:52:45 <nitzmahone> 👍
20:52:49 <jhawkesworth_> need to read some more as I think to be useful you might want to also specify reboot time
20:53:07 <jhawkesworth_> which Ihaven't yet seen an example of tweaking via PS
20:54:04 <jhawkesworth_> also not sure about validating the active hours window size, which I believe started at 12 hours but in some later builds is 18 hours
20:54:43 <jhawkesworth_> nothing else from me (need to finish Fest talk proposal!)
20:54:45 <jborean93> I've heard some pretty gnarly stuff about the active hours and windows automatic reboot behaviour
20:55:39 <jborean93> yep I'm all good, just trying to get through the backlog of PRs and Issues I left lingering. Hopefully get through most of the active ones by the end of this week
20:56:36 <jhawkesworth_> we have some clusters which run across a lot of nodes, I really want a way to make sure they aren't all going to reboot at the same time
20:58:40 <jborean93> cool, if there's nothing else will bring it to a close
20:58:47 <jborean93> thanks all
20:59:27 <jborean93> #endmeeting