20:00:23 <jborean93> #startmeeting Ansible Windows Working Group 20:00:23 <zodbot> Meeting started Tue Apr 2 20:00:23 2019 UTC. 20:00:23 <zodbot> This meeting is logged and archived in a public location. 20:00:23 <zodbot> The chair is jborean93. Information about MeetBot at http://wiki.debian.org/MeetBot. 20:00:23 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic. 20:00:23 <zodbot> The meeting name has been set to 'ansible_windows_working_group' 20:00:27 * nitzmahone too slow 20:00:42 * nitzmahone got as far as `#startmeeting Ans` 20:01:07 <jhawkesworth> hey 20:01:40 <jborean93> hey 20:01:52 <jborean93> #chair nizmahone jhawkesworth 20:01:52 <zodbot> Current chairs: jborean93 jhawkesworth nizmahone 20:01:59 <jborean93> nitzmahone: I have a few hours head start :) 20:02:19 <nitzmahone> heh 20:02:37 <nitzmahone> you still need to send me tomorrow's lottery numbers 20:02:58 <jhawkesworth> :-) 20:03:53 <jborean93> anywho, lets look at the agenda 20:04:03 <nitzmahone> just https://github.com/ansible/ansible/pull/53925 20:04:44 <jborean93> except for the tests, my last comment is around https://github.com/ansible/ansible/pull/53925#discussion_r270684100 20:04:52 <nitzmahone> Looks like there were still a couple open issues around idemp etc 20:04:58 <jborean93> yea 20:05:08 <jhawkesworth> yep its nice but for idempotency 20:05:47 <jborean93> chopraaa still has some time before the community freeze so hopefully we can get to a result sometime soon 20:05:51 <nitzmahone> Still one more week if he wants to get it in 20:06:06 <nitzmahone> (got bumped again due to paramiko packaging issues in RHEL7++ 20:06:20 <jhawkesworth> ah ok I thought it was 4th April 20:06:27 <nitzmahone> It was 20:06:34 <nitzmahone> At least it wasn't my fault this time ;) 20:06:42 <jborean93> :) 20:07:09 <jhawkesworth> fault? new stuff takes as long as it takes 20:07:14 <nitzmahone> Well, anything else for today, or short meeting? 20:07:42 <nitzmahone> jhawkesworth- "development is like a gas- it will consume all available time" 20:07:47 <nitzmahone> (and then some) 20:07:55 <nitzmahone> hey, speak of the devil 20:08:00 <nitzmahone> welcome chopraaa 20:08:06 <chopraaa> hey 20:08:06 <jhawkesworth> nice, not heard that one before 20:08:08 <jborean93> hey 20:08:10 <jhawkesworth> heya 20:08:25 <chopraaa> sorry i have to do chef stuff at work now. :l been keeping busy 20:08:28 <nitzmahone> actually s/consume/expand to fill/ 20:09:07 <jhawkesworth> no worries, we understand its what you can do and when you can do it. 20:09:09 <nitzmahone> Well, you've got another week for win_format in 2.8 if you want to tweak up the force_format behavior ;) 20:09:27 <chopraaa> yeah about that 20:09:41 <chopraaa> wasnt very confident with my initial PR so I was hoping for input 20:09:55 <chopraaa> and I have a good feeling with the direction we're taking on it now :D 20:10:14 <jborean93> chef! are you allowed to be here :P 20:10:39 <jborean93> everything else looks good though about the module. Just some slight tweaks to the tests and this idempotency stuff is all that's left 20:10:46 <jhawkesworth> yeah I think we talked about it a little while ago, not sure I fully understood your concern about idempotency at the time 20:11:00 <jhawkesworth> yeah would be great to get it in 20:11:14 <chopraaa> cheers, shouldn't be long now 20:11:56 <jhawkesworth> as long as you are using ansible to automate chef that's fine :-) 20:12:43 <chopraaa> not doing it by choice lol 20:13:06 <chopraaa> that time of the year where i get a raise 20:13:26 <nitzmahone> I've seen some pretty unholy marriages of Ansible/Chef/Puppet/Salt/others; you do what you gotta do ;) 20:13:34 <jhawkesworth> yeah, do what you need to do 20:13:52 * chopraaa is open to referrals at RH 20:13:56 <jhawkesworth> I've heard of ansible being used as a puppet delivery system. Ouch 20:14:48 <chopraaa> Had to do a bit of research on both Puppet and Chef, and what I found on their websites (about Ansible) is a bit unsettling 20:15:20 <chopraaa> Blatant misinformation. Back when Michael was doing this solo. :/ 20:15:46 <jborean93> seems to be the common scenario 20:16:09 <jborean93> I can't say I know enough about Chef/Puppet/Salt to really explain their advantages and disadvantages 20:16:24 <jhawkesworth> yeah me neither 20:16:35 <jborean93> Have been meaning to work with them some more to get a better handle of what they do better 20:17:01 <jhawkesworth> puppet didn't really work for us in dev, I found ansible and I'm still here! 20:17:25 <jhawkesworth> anyway .. off topic 20:17:26 <chopraaa> Windows needs some sort of a pull mode 20:18:39 <jhawkesworth> personally never found the need for a pull mode 20:18:41 <nitzmahone> The technical hurdles to a Windows controller are falling quickly, the hard part is deciding how it should behave when you're running Python modules against localhost (plus other POSIX-isms like the `pipe` lookup) 20:18:42 <jborean93> would be nice, I know nitzmahone has a few ideas on that going round his head 20:19:30 <jhawkesworth> yeah no standard python for windows either, which I guess complicates things a little 20:19:36 <nitzmahone> Not so much 20:19:58 <chopraaa> Would love to help test anything where I can 20:20:28 <chopraaa> I had a good time using pypsrp :-D 20:21:10 <nitzmahone> It's honestly probably not going to be a priority anytime soon, unless/until Red Hat starts going after Windows-only customers 20:21:16 <jhawkesworth> been using pypsrp in dev for a couple of months 20:21:22 <nitzmahone> Most mixed shops have no problem with the Linux controller 20:21:44 <jborean93> jhawkesworth: hopefully without any major issues? 20:22:20 <jhawkesworth> a few timeouts, but not in a pattern I can spot, but otherwise its been great, perhaps even a little faster 20:23:16 <jhawkesworth> not sure if the timeouts are just overprovisioned vmware or actually indicative of anything at this point 20:24:40 * jhawkesworth makes note to run azure stuff via pypsrp 20:25:37 <nitzmahone> Well, anything else for today? 20:26:02 <jborean93> anyone interested in proxy stuff I've got 2 modules ready for review 20:26:15 <jborean93> https://github.com/ansible/ansible/pull/54631, it's close to ready for a merge but any extra reviews would be great 20:27:18 <jhawkesworth> I will look it over but not something I have a use for at the moment 20:27:33 <jborean93> no worries 20:27:51 <jborean93> johnboy2 has been quite thorough which is great 20:28:19 <jhawkesworth> are we still being cautious about switching modules to use Basic instead of Legacy still? 20:28:39 <jborean93> up to the module author I think 20:28:53 <jhawkesworth> ok 20:28:59 <nitzmahone> (ie I don't think we're at the point that we want to force update all of them) 20:28:59 <jborean93> not sure if that will change for 2.9 20:29:38 <nitzmahone> Probably wouldn't be a bad idea to do whatever core-supported stuff that hasn't cut over yet for 2.9 though 20:29:54 <jborean93> yea, I hope most of the hairy stuff has been caught 20:29:55 <jhawkesworth> I didn't for the win_xml changes as it had enough change it it for one PR already, but thinking just as things get opened up, start switching them now 20:30:02 <jhawkesworth> ok 20:30:14 <jborean93> I'm sure once 2.8 is out more things will come out of the woodwork that we can safely convert some more across afterwards 20:30:28 <jhawkesworth> fair enough. 20:30:57 <chopraaa> I had a question about return values for win_partition 20:30:59 <jhawkesworth> fwiw running azure stuff from 2.8 dev, haven't had to modify much yet 20:31:14 <nitzmahone> chopraaa: go for it 20:31:15 <jhawkesworth> go ahead 20:31:29 <chopraaa> Sort of slipped my mind, and I can't really recall what I had to ask... 20:31:58 <chopraaa> Right, is there a particular way we deal with return values when using check_mode? 20:32:19 <jborean93> that's a hard one 20:32:19 <nitzmahone> where reasonable, return the same-shaped data as you would 20:32:20 <chopraaa> Some values I'd like to get only if a partition gets created, and this isn't the case using check mode 20:32:39 <jborean93> potentially you could "mock" the value if possible 20:32:58 <jborean93> it keeps the return values consistent even in check mode, the values just won't really be useful 20:33:07 <jhawkesworth> yeah you are at the mercy of what powershell/.net/windows gives 20:33:34 <chopraaa> Just feels odd 20:33:51 <jborean93> if it's a guid, I would do `[Guid]::Empty` or something like that 20:33:54 <jhawkesworth> but if you can keep the keys /json structure the same, that's really useful 20:34:21 <chopraaa> The module has the option of picking whatever drive letter is available so at most, I can check which letter is free and then return a value. 20:34:35 <jborean93> that sounds good 20:34:36 <jhawkesworth> if the json structure is the same you can still test / assert / do when conditions on it 20:34:53 <jborean93> I've done something similar to win_user_profile where the path returned in check mode is the expected path that would have been created 20:34:57 <nitzmahone> Yeah, otherwise it makes it difficult to run a playbook in check_mode that looks at results, since you'd have to put a lot of conditional filter/default magic around everything to keep the template engine happy 20:35:01 <chopraaa> But the case is the same for a bunch of parameters and not just this one, so it's a lot of risk 20:35:23 <jhawkesworth> no doubt been bitten by registering a `file` result and then failing on the file.exists test in next step 20:35:31 <nitzmahone> Ideally you'd be setting them to their default values upfront, then updating them as the real code runs 20:35:37 <chopraaa> And another one 20:35:41 <jborean93> if it isn't possible then at least document that it doesn't get returned in check mode 20:36:00 <chopraaa> Most modules return a value if changed/successful 20:36:13 <chopraaa> Is it a good idea to return values if a *partition* is changed/created? 20:36:52 <jborean93> depends on the value but if it makes sense I would 20:36:53 <nitzmahone> Usually, your module should only return info that's not easily gained from a facts module or something 20:37:02 <chopraaa> If you delete a partition > module returns changed but has no return values 20:37:22 <chopraaa> If you create a partition > module returns changed and has return values 20:37:33 <chopraaa> And these return values are really useful 20:37:39 <chopraaa> for win_format for instance 20:37:42 <jborean93> what's the return value here? 20:37:55 <chopraaa> volume paths or drive letters 20:37:58 <nitzmahone> Return values shouldn't duplicate invocation info 20:38:14 <chopraaa> @nitzmahone yep 20:38:19 <jborean93> in this case it could be derived though, e.g. you specify the volume name and get the drive letter back 20:38:21 <nitzmahone> So if the module/system assigned a drive letter randomly, returning it is *good( 20:38:29 <jborean93> yep 20:38:31 <nitzmahone> (because it's new information) 20:39:11 <chopraaa> cant return a path to a volume in check mode, or if the volume has been deleted 20:39:20 <chopraaa> so these were my concerns 20:39:58 <jborean93> if the volume is deleted you could return what the path was that was removed 20:40:09 <chopraaa> well not paths, object ids 20:40:15 <jborean93> sorry yep 20:40:29 <chopraaa> okay that sounds good 20:40:42 <nitzmahone> yeah, ideally the "shape" of the return value is always the same 20:40:58 <chopraaa> im still unsure what shape is o.o 20:41:09 <chopraaa> the json struct? 20:41:12 <nitzmahone> Like the values returned, the depth of the dict, etc 20:41:13 <nitzmahone> yeah 20:41:34 <chopraaa> ah cool cool. i get it 20:41:38 <nitzmahone> rather than "if I did X, it looks like this, if I did Y, it looks like that" 20:41:47 <nitzmahone> much harder to document that way 20:41:52 <nitzmahone> (+ test, + use) 20:42:42 <jborean93> also removed complication if you know this value is returned always 20:43:10 <chopraaa> ill dig into this the next few days 20:43:21 <chopraaa> see what looks best 20:43:30 <jhawkesworth> thank you 20:44:03 <nitzmahone> OK, anything else today? 20:44:13 <jhawkesworth> not from me 20:44:15 <jborean93> I'm good 20:44:18 <chopraaa> im good 20:44:38 <jhawkesworth> let nitzmahone get his lunch then 20:44:46 <nitzmahone> Heh, I ate early today ;) 20:45:06 <jhawkesworth> :-) 20:45:13 <nitzmahone> OK, til next week then! 20:45:15 <nitzmahone> Thanks all 20:45:17 <nitzmahone> #endmeeting 20:45:22 <jhawkesworth> cheers 20:45:51 <nitzmahone> doh, jborean93 misspelled my nick, he or Jon will have to close the meeting 20:45:59 <jborean93> #endmeeting