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