20:00:02 <nitzmahone_> #startmeeting Ansible Windows Working Group
20:00:02 <zodbot> Meeting started Tue Sep  8 20:00:02 2020 UTC.
20:00:02 <zodbot> This meeting is logged and archived in a public location.
20:00:02 <zodbot> The chair is nitzmahone_. Information about MeetBot at http://wiki.debian.org/MeetBot.
20:00:02 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
20:00:02 <zodbot> The meeting name has been set to 'ansible_windows_working_group'
20:00:07 <nitzmahone_> bah
20:00:16 <nitzmahone_> #chair jborean93
20:00:16 <zodbot> Current chairs: jborean93 nitzmahone_
20:00:21 <briantist> 👋hey hey
20:00:26 <nitzmahone_> howdy
20:00:30 <jborean93> yo
20:01:11 <nitzmahone_> Nothing on the agenda for today
20:01:13 <nitzmahone_> #topic open floor
20:01:23 <jborean93> I've got one for today
20:01:31 <nitzmahone_> go for it
20:01:59 <jborean93> https://github.com/ansible-collections/community.windows/pull/130#discussion_r484567275
20:02:00 <jhawkesworth> hey
20:02:10 <jborean93> talking about the `recursive` option for delete in a new module
20:02:32 <jborean93> We don't require that for something like win_file when deleting a non-empty directory and my thoughts is it should be the same here
20:02:45 <jborean93> But deleting an OU could have bigger ramifications
20:03:35 <briantist> hm, so the behavior with `recursive=false` and attempting to delete an OU with children would do what? throw an error?
20:03:59 <jborean93> yep
20:04:07 <briantist> also, does it only count as recusrive if it has other OUs/containers, or any objects exist in the OU?
20:04:24 <nitzmahone_> I also usually lean toward the "just do what I asked" behavior vs the guardrails that are usually placed on interactive tools
20:04:30 <jborean93> https://github.com/ansible-collections/community.windows/pull/130/files#diff-ed4fd51d61213a097746f7ec0905c164R153-R154
20:04:58 <jborean93> it's basically whatever `Remove-ADOrganizationalUnit` does with and without the `-Recursive` switch
20:05:05 <briantist> I see, looking into that
20:05:10 <nitzmahone_> https://docs.microsoft.com/en-us/powershell/module/addsadministration/remove-adorganizationalunit?view=win10-ps
20:05:15 <nitzmahone_> Any child objects
20:05:41 <nitzmahone_> (so IIUC the cmdlet will fail if there's anything inside the OU without `-Recursive`)
20:05:48 <jborean93> yep
20:05:56 <jborean93> similar to `Remove-Item` on a dir with children
20:06:21 <nitzmahone_> I'm +1 to just nuking `recursive` and making that the default behavior. Getting an OU truly empty can be... challenging ;)
20:06:30 <briantist> yeah, I think I'm with you both on not having it as an option, and letting it delete
20:06:49 <nitzmahone_> (esp if you're just doing it with Ansible)
20:06:53 <briantist> the AD recycle bin shouldn't be disabled on any modern domain and provides a dead simple remediation
20:06:58 <jhawkesworth> no objection from me
20:07:18 <jborean93> cool, was mostly my thought that if you define a state in Ansible it should do it rather than having a further check
20:07:21 <jhawkesworth> I get the feeling I am lucky never to have had to do this!
20:07:26 <briantist> if we wanted some safety switch, I'd rename it to `empty_only` (bool) and make it `false` by default
20:08:06 <nitzmahone_> Not sure I'd even bother though- would you even be able to fully empty an OU in Ansible (only) of arbitrary objects?
20:08:19 <nitzmahone_> (without resorting to `win_shell` or some such)
20:09:02 <nitzmahone_> jhawkesworth: yeah, it's a scary thing to do :)
20:09:25 <briantist> I don't think I'd bother either. It mostly wouldn't be a question of whether you could, it's more that you'd set it when you THINK you can't possible be running it against anything but an OU that's already empty; it would be the safety net.
20:09:40 <briantist> But it would have pretty limited utility tbh
20:11:04 <nitzmahone_> Sounds like we're pretty much in agreement then- just nuke `recursive` arg and make that behavior the default
20:11:17 <jhawkesworth> +1
20:11:18 <briantist> 👍
20:11:41 <jborean93> sounds good to me
20:11:43 <jborean93> will relay that on
20:12:48 <nitzmahone_> I've got a random poll question that's not really Windows-related, but only if anyone besides jborean93 publishes stuff with ansible-galaxy...
20:13:47 <jhawkesworth> another thing I've never quite got round to, 'fraid to say, but that might not stop me having an opinion on it ;-)
20:14:09 <nitzmahone_> The GitHub service that underlies `ansible-galaxy login` is going away- I threw together a replacement for it, but the Galaxy team are like "just get rid of it and require manual token management everywhere" (eg, get your token from the Galaxy UI and always provide it on `ansible-galaxy collection publish` (etc) with `--token`.
20:15:08 <nitzmahone_> (`login` lets you create and store a token locally so there's an ambient credential)
20:15:28 <briantist> I haven't published anything there. Maybe that would change in the future when I get more familiar with collections. But I expect most of my interaction there will be installing from git repos directly and not via publishing to galaxy
20:15:31 <nitzmahone_> Kinda like `az login` for Azure
20:15:41 <jborean93> personally I think they should implement the OAuth stuff, it's a hassle when someone wants to work on the cmdline but I know that's a long shot to getting it implemented properly
20:16:04 <briantist> based on that description, that sounds like a useful service. Having to manually go to a web page and grab a token seems annoying and somewhat anti-automation
20:16:05 <nitzmahone_> jborean: it does?
20:16:37 <jborean93> I mean there doesn't seem to be any appetite to add new features to galaxy.ansible.com
20:16:43 <nitzmahone_> The replacement I wrote uses OAuth device flow (just like Azure CLI)
20:16:56 <jborean93> so I doubt they would implement the client_id stuff that you require for that to work properly
20:17:24 <nitzmahone_> Yeah, that's the only problem
20:17:52 <jhawkesworth> I guess 'leave the door' open to changing later if you can.
20:17:58 <nitzmahone_> I mean I could make it work for production galaxy only and just say "sorry, go get your own token" if you try to use `ansible-galaxy login` on anything else...
20:18:18 <jborean93> you could just link to the Galaxy UI page
20:18:53 <nitzmahone_> The auth part actually works anyway, even with the "wrong" client_id
20:19:13 <jborean93> weird
20:19:30 <nitzmahone_> I don't know what all the server does with that token (if anything) later (eg, passing it on to GitHub for delegated operations during role publish)
20:21:49 <jborean93> I know they tried to suggest login be deprecated in 2.9
20:22:25 <nitzmahone_> I don't care, since I don't use that tooling myself anyway, but hoping to find out if that'll be a major hardship.
20:22:26 <jhawkesworth> well my $0.01 is it seems unlikely there are many right now who would be greatly inconvenienced by manual token.  If partners aren't concerned and Jeff Geerling is ok with it, it doesn't feel like it is going to bite a lot of folks hard
20:23:14 <nitzmahone_> Yeah, I'm not gonna complain about just killing my PR, especially since we can't easily do any automated testing to verify the device flow (since it requires an out-of-band browser session)
20:23:53 <nitzmahone_> OK- I'll probably bring it up in the next main IRC meeting too and if there's no big pushback, just kill it
20:24:04 <jborean93> sounds good
20:24:20 <jhawkesworth> yeah that AZ login is probably pretty secure but automatically testing that would be ''fun''
20:24:50 <nitzmahone_> Well, nothing else from me today- thanks for the opinions!
20:25:22 <jhawkesworth> ha ha you're welcome.  Nothing from me (again).
20:25:41 <jhawkesworth> I'm gonna drop, catch y'all next time.
20:25:47 * jhawkesworth afk
20:25:50 <nitzmahone_> 👋
20:26:05 <nitzmahone_> If nothing else for today, will close in 2min...
20:26:50 <briantist> nothing else from me
20:28:08 <nitzmahone_> OK then, til next week- thanks all!
20:28:11 <nitzmahone_> #endmeeting