20:00:15 <nitzmahone> #startmeeting Ansible Windows Working Group
20:00:16 <zodbot> Meeting started Tue Jan  9 20:00:15 2018 UTC.  The chair is nitzmahone. Information about MeetBot at http://wiki.debian.org/MeetBot.
20:00:16 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
20:00:16 <zodbot> The meeting name has been set to 'ansible_windows_working_group'
20:00:38 <jborean93> o/
20:00:39 <nwsparks> hey
20:00:49 <nitzmahone> #chair nwsparks jborean93
20:00:49 <zodbot> Current chairs: jborean93 nitzmahone nwsparks
20:00:52 <dag> o/
20:00:58 <nitzmahone> #chair dag
20:00:58 <zodbot> Current chairs: dag jborean93 nitzmahone nwsparks
20:01:13 <dag> completely distracted with a daughter who has a sleeping-disorder :-(
20:01:52 <nitzmahone> #info agenda: https://github.com/ansible/community/issues/195
20:03:02 <nitzmahone> #topic: win_disk_X modules
20:03:11 <nitzmahone> https://github.com/ansible/ansible/pull/27634
20:03:17 <nitzmahone> https://github.com/ansible/ansible/pull/32935
20:03:47 <nitzmahone> Oh, looks like facts one got merged
20:03:53 <jborean93> Pretty much balls down to this is doing too much and it touches multiple components of disks (volumes, partitions, formatting)
20:03:58 <jborean93> Yea the facts were cool
20:04:30 <nwsparks> I'm looking over it now.
20:05:03 <jborean93> Here were my thoughts at the time https://github.com/ansible/ansible/pull/27634#pullrequestreview-83695637
20:06:35 <nwsparks> I would agree. Aside from the reasons you outlined, there are some use cases where'd you want to be able to set disks online/offline...so having disk management as it's own module would potentially be useful
20:06:42 <dag> Always if I approve something, and someone else comes up with review items, I feel like good cop, bad cop :-)
20:07:36 <nitzmahone> Meh, that's why we have multiple sets of eyeballs on things- we're all looking/thinking about different things, so I see that as a normal part of the process
20:07:50 <jborean93> you've got to temper the reviews with positive comments, overall I had a hard time reviewing it as it was just really long and complex which didn't help to begin with
20:09:07 <nitzmahone> OK, so we just waiting to see what he wants to do next then?
20:09:29 <jborean93> Well I think we should reject the PR and close it on those ground
20:09:41 <jborean93> Either he can do the work to split it or we can wait until someone else has time
20:09:51 <nitzmahone> and say "reopen as multiple smaller modules if you want"?
20:09:58 <jborean93> Yep
20:09:58 <nitzmahone> WFM
20:10:10 <nwsparks> Sounds good to me
20:10:21 <dag> my only objection would be the potential disappointment...
20:10:34 <dag> 119 commits, 200 comments...
20:10:37 <jborean93> Yea it's been open for a while but I don't want to support this module if it goes in
20:10:46 <dag> I do understand
20:10:47 <jborean93> I did merge his disk facts as that was good
20:11:10 <nwsparks> That's true...but, it shouldn't be too unreasonable to split up the work he's already done hopefully
20:11:24 <dag> I would certainly hope so :)
20:11:25 <nwsparks> assuming he's interested in doing it
20:11:49 <jborean93> Plus if this works for him he can still continue to use it privately or upload to galaxy
20:11:56 <nwsparks> True
20:12:10 <jhawkesworth_> Me lurking / catching up
20:12:12 <nitzmahone> OK, looks like that's the end of the agenda stuff....
20:12:16 <nitzmahone> #topic open floor
20:12:18 <nitzmahone> mind the gap
20:12:41 <jborean93> This is probably something for nitzmahone and I to talk offline but I've got 2 PR's for become flag support on runas
20:13:08 <nitzmahone> Would be curious to hear others' thoughts on that if anyone has an opinion
20:13:27 <jborean93> https://github.com/ansible/ansible/pull/33297 <- dict support
20:13:36 <jborean93> https://github.com/ansible/ansible/pull/34551 <- key=value as string
20:13:48 <jhawkesworth_> Can you elaborate on what flag support is
20:14:02 <jborean93> Ultimately runas will become on an interactive logon session
20:14:12 <nitzmahone> So we can pass options to become/runas without implementing a phony cmdline for it
20:14:17 <jborean93> This allows you to control it so you can do a batch logon instead
20:14:26 <jborean93> But the big benefit I see is the netcredential support
20:14:28 <nitzmahone> (since become_flags currently assumes that you're passing extra args to su/sudo/etc)
20:14:58 <jborean93> Where you can run the process as the current user locally but when talking to a network device it presents the become credentials instead
20:14:59 <nitzmahone> We didn't want to have to implement a phony cmdline format for become/runas
20:15:44 <nitzmahone> Yeah- I see that as completely superseding the win_package credentials support
20:15:48 <jborean93> Yep
20:15:56 <jborean93> Plus it will work with win_copy with a remote fileshare
20:16:03 <nitzmahone> (and obviating the need for it on lots of other modules)
20:16:32 <jhawkesworth_> Net credential behavior sounds very useful
20:16:35 <nitzmahone> People keep filing issues/PRs to add credential support to arbitrary modules- this would take care of that
20:17:06 <jborean93> I haven't tested it with a non Windows SMB share but it worked with local user authorising with a domain fileshare with domain creds
20:17:12 <jhawkesworth_> Every windows shop seems to want to drag files on and off shares
20:17:24 * dag is on the phone :-/
20:17:40 <jborean93> Seems to be the standard with Windows shops unfortunately
20:17:44 <nitzmahone> Makes sense though- I understand why...
20:18:13 <nitzmahone> Shipping stuff through the controller sucks, and using tempfiles/win_get_url/etc is ... suboptimal
20:18:41 <jborean93> In the end, the 1st PR is more intrusive into the become mechanism in Ansible itself while the 2nd keeps that the same and the parsing is done by the become wrapper
20:18:48 <nitzmahone> Doing it with shares is arguably brittle for really big things, but it's a quick way to distribute stuff in a single site
20:18:59 <jhawkesworth_> Would be great to have it though, I think working with file shares is a stumbling block for many trying to automate windows
20:19:29 <jborean93> It's probably one of the last become things I wanted to do for 2.5, arguably the only thing left is password become support
20:20:34 <jborean93> s/password/passwordless/
20:21:12 <nitzmahone> Did you get anywhere with that?
20:21:20 <jborean93> Didn't try it yet
20:21:31 <jborean93> Was going to aim for 2.6 if I wanted to try it out
20:21:34 <nitzmahone> I'm definitely not going to have time to play with it for 2.5...
20:21:54 <nitzmahone> Depending on how invasive, it might need to wait for 2.7
20:22:20 <nitzmahone> I don't think we're completely abolishing new features for 2.6, but it's supposed to be mostly stabilization
20:23:05 <jborean93> It's not critical for passwordless support IMO but I can see the need
20:23:32 <nitzmahone> Oh, we'll definitely get at least the KV version in- I'm actually leaning toward the real dict version though
20:23:57 <jborean93> I need to rebase and clean up the become wrapper parser to be a bit more efficient
20:24:17 <jborean93> But was hoping for some feedback based on don't do that :)
20:25:51 <nitzmahone> Yeah, I'm like +0.75 on the dict one
20:26:20 <jhawkesworth_> I'll take a look at the PRs but irc via phone making it difficult
20:26:51 <nitzmahone> Yeah, the dict one especially would be painful to review on a phone
20:28:18 <nitzmahone> Well, we'll get that one sorted anyway- I think dict version is the way to go.
20:28:24 <nitzmahone> Anything else for today?
20:28:40 <jborean93> Sounds good, feel free to add comments to either for anyone else who reviews it in the future
20:29:32 <nwsparks> I'm going to do another PR for win_iis_webbinding, not sure if it would be best to discuss here or in the PR
20:29:54 <nwsparks> Identified an issue resulting from https://github.com/ansible/ansible/issues/30412 which is a minorish change
20:30:18 <nwsparks> but I had also worked in some logic to try and prevent binding conflicts when the protocol is SSL
20:31:18 <jborean93> Cool, is there anything in particular you wanted to talk about?
20:31:30 <nwsparks> I came across a use case I didn't think of previously (subject alternative name certs)...I'm thinking I'm just going to remove all of the verification around preventing binding conflicts since I'm having trouble thinking of ways to cover it all
20:33:01 <nwsparks> I guess not much to discuss now that I am typing it out, that was the main thing though. I guess I'll just do the PR and we can comment in it
20:33:15 <nitzmahone> Yeah, you'd basically have to hash all the values/defaults
20:34:00 <nwsparks> Yah it's just tough because a conflict is fine if the existing certs are wildcard or san or if sni is enabled
20:34:05 <nwsparks> existing bindings*
20:34:42 <nwsparks> and a number of other combinations with the incoming binding
20:34:57 <nwsparks> so I'm worried about blocking legitimate activities I didn't account for
20:35:07 <jhawkesworth_> sounds v hard to have sane verification then
20:35:28 <nwsparks> yah...I thought I had it reasonably well done until the san cert thing came up
20:35:47 <nwsparks> so I am thinking best to just scrap it before 2.5 rather than let it go and cause blocks for people
20:36:00 * jborean93 dodged a bullet by not refactoring the rest of the iis modules
20:36:04 <nwsparks> lol
20:36:16 <nwsparks> this one seems like the worst just because of this particular issue
20:36:47 <jborean93> I could be thinking of the wrong this but isn't just the thumbprint required to verify the cert needs to be changed
20:37:04 <jborean93> e.g. if the SAN, subject, issuer changes then the thumbprint is different
20:37:34 <nitzmahone> Thumbprint is definitely the easy way to solve it, rather than a high-level cert selector, if that's what you were thinking
20:37:50 <nitzmahone> Effectively a UUID for a cert
20:37:54 <nwsparks> Yah, that part is ok and I'm leaving it. This particular issue would be something like a binding exists on a different site than what I am targetting say on *:443 no host header
20:38:17 <nitzmahone> That's an allowed config though with SNI
20:38:22 <nwsparks> If I try and bind to *:443 on a new site with a different cert, the native powershell cmdlets for it won't actually stop me from doing it
20:38:37 <nwsparks> Instead I'll just end up with a stopped site because it will conflict
20:39:12 <nwsparks> but in the scenario that the *:443 site A is bound with a wildcard, and my new binding is *:443 no SNI with hostheader, the operation is fine and there is no conflict
20:39:36 <jborean93> Hmm that sounds like that's just bad input from the user which we may not want to verify ourselves
20:40:07 <nwsparks> Yah that's what I am thinking now as well. I was hoping to help people out with the logic around preventing it but it just seems to troublesome at this poin t
20:41:00 <jborean93> I don't know if it is a valid scenario but potentially that will also stop someone from creating a stopped site with a conflicting binding as another site
20:41:48 <nwsparks> Possibly
20:43:05 <nitzmahone> Regardless, probably best to punt for now rather than potentially limiting a valid scenario that worked in the past
20:43:40 <nwsparks> Ok. I'll do a new PR probably tomorrow and we can review it further there.
20:43:46 <jborean93> sounds good
20:44:05 <jhawkesworth_> nice.  thanks for tackling iis management stuff
20:44:26 <nwsparks> no problem
20:45:33 <jhawkesworth_> most of our stuff offloads https elsewhere so I don't have any experience of anything complex involving cert binding in IIS
20:46:22 <nwsparks> it's generally not too bad...especially now that SNI is a thing. It was a pain in 2k8 though if you had a lot of sites
20:49:06 <nitzmahone> OK, if nothing else, we'll wrap it up for the day...
20:49:23 <nwsparks> Nothing for me
20:49:55 <jborean93> I'm good
20:49:58 <jhawkesworth_> Yeah.  this week I'm just trying to go through bug reports .  If I can get my current fully automated deployment stuff done in time I want to migrate my playbooks to devel / 2.5 syntax but not sure I'll get agreement for it yet
20:50:28 <jhawkesworth_> best let you get on then.
20:50:30 <jhawkesworth_> cheers
20:51:24 * jhawkesworth_ afk
20:51:41 <jborean93> sounds good, thanks everyone for coming
20:52:20 <jborean93> #endmeeting