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