20:00:42 <jborean93> #startmeeting Ansible Windows Working Group
20:00:42 <zodbot> Meeting started Tue Sep  4 20:00:42 2018 UTC.
20:00:42 <zodbot> This meeting is logged and archived in a public location.
20:00:42 <zodbot> The chair is jborean93. Information about MeetBot at http://wiki.debian.org/MeetBot.
20:00:42 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
20:00:42 <zodbot> The meeting name has been set to 'ansible_windows_working_group'
20:00:45 <dag> o/
20:00:47 <jhawkesworth_> hey
20:00:49 <jborean93> yo
20:00:57 <jborean93> #chair dag jhawkesworth_
20:00:57 <zodbot> Current chairs: dag jborean93 jhawkesworth_
20:01:14 <jborean93> #chair nitmzahone
20:01:14 <zodbot> Current chairs: dag jborean93 jhawkesworth_ nitmzahone
20:01:21 * jborean93 sigh
20:01:23 <nitzmahone> o/
20:01:26 <jborean93> #chair nitzmahone
20:01:26 <zodbot> Current chairs: dag jborean93 jhawkesworth_ nitmzahone nitzmahone
20:02:24 <jborean93> so 2.7 is in feature freeze, anything we want to talk about in relation to bug fixes with that release?
20:03:40 <nitzmahone> nothing from me ATM
20:04:04 <jhawkesworth_> just noticed https://github.com/ansible/ansible/issues/45188 - surprising, but none of the tests cover having request params
20:04:40 <dag> jhawkesworth_: I was just testing this, but it works like a browser would, I think that's intended though
20:05:12 <nitzmahone> Hrm, wonder if we have some PS magic to thank for that
20:05:31 <nitzmahone> or more likely the "it's IE under the covers" thing
20:06:12 <jborean93> we don't expose the normal cmdlet param that controls to use IE under the covers
20:06:23 <jborean93> so not sure if the .net class has that or whether PS uses something different
20:07:49 <jborean93> the docs for WebClient don't seem to indicate it exposes that functionality
20:07:58 <dag> no, I checked too
20:09:05 <jborean93> we do have use_basic_parsing in win_uri but that's noop now that the module uses the .NET object directly and not the PS cmdlet
20:09:29 * jborean93 looks like we were meant to get rid of it in 2.7
20:09:43 <dag> if you provide the URL with a % sign, it will turn this into an encoded %DD char too
20:10:03 <jhawkesworth_> I wonder if the `protected override WebRequest GetWebRequest(System.Uri address) {` is maybe messing things up
20:10:25 <jhawkesworth_> L25-29
20:11:02 <jborean93> `#2F` is meant to be `/` it seems
20:11:18 <dag> jhawkesworth_: no, because I excluded that in my example
20:11:34 <dag> jhawkesworth_: I used the original WebClient
20:11:59 <jborean93> so I understand the case where they want that element encoded
20:13:23 <jborean93> wonder if we need to use `Uri.UnescapeDataString(url)` and have a flag that controls whether to use the unescaped version
20:14:12 <jborean93> would need to test it to see if it works though
20:14:13 <dag> let me test
20:15:02 <jborean93> nope didn't work for me
20:15:06 <jborean93> was still converted to `/`
20:16:47 <jborean93> sigh
20:16:58 <jborean93> classic MS, add a flag in the config file for your app to control this behaviour https://stackoverflow.com/questions/781205/getting-a-url-with-an-url-encoded-slash
20:17:05 <dag> I know that the vCenter nterface had an issue where the only solution is to provide it with a double-encoded string
20:17:54 <jborean93> and that is dependent on different .NET versions..
20:17:59 <jborean93> god I hate .NET sometimes
20:18:32 <jhawkesworth_> ugh, that's nasty
20:18:39 <dag> https://github.com/ansible/ansible/blob/devel/lib/ansible/modules/cloud/vmware/vsphere_copy.py#L106
20:19:08 <jborean93> looks like it's done as a security precaution https://docs.microsoft.com/en-us/dotnet/framework/configure-apps/file-schema/network/schemesettings-element-uri-settings#remarks
20:19:17 * nitzmahone shakes fist at behavior that can only be controller via app config/manifest
20:19:48 <jborean93> seems to be MS go to solution
20:20:20 <jborean93> looks like there's hacks to get it working but it won't be an easy/nice fix
20:21:05 <dag> haha, so any legitimate use is impossible because people could abuse it (with broken apps)
20:21:31 <dag> anyway, anything more important to discuss ?
20:21:32 <nitzmahone> Yeah, anyone writing something that does what their example does deserves what they get
20:22:08 <nitzmahone> Nothing here
20:22:09 <jborean93> in their defense, looks like a gitlab behaviour
20:22:29 <nitzmahone> (PS, also fixed if you compile against .NET 4.5, so I wonder if PS5.1 exhibits this behavior?)
20:22:45 <nitzmahone> s/compile against/target framework/
20:23:03 <jborean93> the URI class automatically converts in 5.1
20:23:11 <jborean93> no idea if WebClient does as well
20:24:05 <jborean93> Only thing I wanted to add was it would be great if people could test out https://github.com/ansible/ansible/pull/44705. I think I've reached the right stop in terms of how it is used by modules but any feedback would be great
20:24:40 <jborean93> the biggest outstanding question is whether the results dict should be part of the class or kept separate and passed in manually
20:26:06 <dag> jborean93: I think it should, be we should allow the same in python
20:26:14 <dag> so it's a standardized way of doing it
20:26:31 <dag> (but should work without doing this in python obviously)
20:26:59 <jborean93> I expect it will be rejected as basic.py seems to be perpetually in the crosshairs for a rewrite
20:27:09 <jborean93> any new functionality will be rejected until that is eventually done
20:27:14 <jborean93> which is who knows whem
20:27:39 <dag> yeah, that seems to be a common theme :-(
20:27:40 <nitzmahone> Which also makes me nervous doing things that are patterned after it, but c'est la vie
20:28:02 <nitzmahone> Someone will pull the trigger right after we nail this down ;)
20:28:07 <jborean93> nitzmahone: anything in particular?
20:28:11 <nitzmahone> not really
20:28:20 <jborean93> I've tried to look at the breaking down doc and hope I got most things
20:28:23 <nitzmahone> Was just hoping we'd keep similar patterns overall
20:28:53 <nitzmahone> I think we'll be fine
20:28:54 <jborean93> I'll try and ask some of the other core members to have a look once it's out of a WIP
20:29:17 <jborean93> but no idea if they just see C# and nope out of there
20:29:27 <dag> jborean93: would this include the exception-handling we put in win_wait_for_process ?
20:29:33 <jborean93> dag: yep
20:29:42 <dag> great !
20:30:35 <dag> I would convert all the modules as soon as this hits the tree
20:30:48 <dag> don't mind doing that work
20:30:50 <jborean93> the most difficult one will be win_dsc
20:30:58 <dag> ok, maybe not that one then :p
20:31:00 <jborean93> but I've got an idea of how to get that working
20:31:22 <jborean93> and to integrate that into the argspec based on the module/resource chosen
20:31:25 <dag> and deprecate the legacy interface over time, but probably not 4 releases
20:31:38 <jborean93> that's the fun side...
20:32:01 <nitzmahone> bonus point for reimplementing legacy on the new one ;)
20:32:14 <dag> jborean93: moving modules over to this will likely reveal some other nice ideas to extend the interface
20:32:43 <jborean93> yep, I'm just wary of deprecating legacy straight away considering the new implementation is bound to have some bugs
20:32:56 <jborean93> basic.py is not an easy beast to try and replicate
20:33:14 <nitzmahone> nor fully tested itself either
20:33:46 <jborean93> yep, I did rip out all the non-module related code, e.g. stuff around file handling and process running
20:35:16 <jhawkesworth_> well it looks good to me.
20:35:29 <dag> nitzmahone: for 2.8 I removed all deprecated stuff from devel, https://github.com/ansible/ansible/pull/45057
20:35:59 <jhawkesworth_> slightly mixed feelings about the api being a little less trivial to pick up, but I guess the trade off is its actually less alien if you have written a python module.
20:36:03 <jborean93> dag: there's win_msi as well
20:37:02 <jhawkesworth_> This https://docs.ansible.com/ansible/devel/dev_guide/developing_modules_general_windows.html#windows-new-module-development and probably other places could with an update once it goes in
20:37:47 <jborean93> jhawkesworth_: definitely, it's a point on the PR that I must do before mering
20:38:17 <jhawkesworth_> cool
20:39:27 <jhawkesworth_> Its annoying there still seem to be things that win_msi will install that win_package won't.
20:39:46 <nitzmahone> Really?
20:40:03 <nitzmahone> Is it just around the "too many moving parts in extra args" thing, or what?
20:40:26 <jborean93> yea I'm wasn't aware that win_msi actually worked
20:40:46 <nitzmahone> Seems like many more circumstances that win_msi breaks than not IME
20:40:48 <jhawkesworth_> I don't think so.  Let me dig around, I just recall having to call msiexec in the end
20:40:56 <jhawkesworth_> oh yeah its plenty broken too
20:41:08 * jhawkesworth_ goes digging
20:41:39 <nitzmahone> Yeah, if there's something that's not working right and you have a repro, it should be something we can fix
20:41:52 <nitzmahone> (esp if you got it working with a direct msiexec call)
20:42:24 <jhawkesworth_> fairly certain it was an inhouse and therefore completely proprietary .msi
20:42:45 <jhawkesworth_> iirc there was someone on ansible-project saying something similar not long ago.
20:44:25 <nitzmahone> Well, let's not let it hold off killing win_msi- if you can find details, file an issue...
20:44:47 * nitzmahone does happy dance to torch win_msi
20:45:12 <jhawkesworth_> agreed, I'd rather it was gone, even if there are places where it has to be replaced with msiexec
20:46:17 <nitzmahone> Anything else for today?
20:46:22 <jborean93> I'm good
20:46:44 <jhawkesworth_> not from me
20:48:06 <jhawkesworth_> hmm, msi could be parameter passing fun
20:48:39 <nitzmahone> k, closing in 5...
20:48:44 <nitzmahone> 4...
20:48:47 <nitzmahone> 3..
20:48:48 <jhawkesworth_> `'msiexec.exe /qn /i C:\deployment\SuperSecret.msi ALLUSERS=1 TARGETDIR=E:\\system\\bin /L*v c:\deployment\log\GetSetDefaultPrinterSetup.log'`
20:48:51 <nitzmahone> 2..
20:48:55 <nitzmahone> 1..
20:49:05 <nitzmahone> #endmeeting