20:00:01 <jborean93> #startmeeting Ansible Windows Working Group
20:00:01 <zodbot> Meeting started Tue Dec 14 20:00:01 2021 UTC.
20:00:01 <zodbot> This meeting is logged and archived in a public location.
20:00:01 <zodbot> The chair is jborean93. Information about MeetBot at https://fedoraproject.org/wiki/Zodbot#Meeting_Functions.
20:00:01 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
20:00:01 <zodbot> The meeting name has been set to 'ansible_windows_working_group'
20:00:06 <briantist> yo
20:00:09 <jborean93> hey
20:01:17 <jborean93> how's it going?
20:01:22 * nitzmahone lurks
20:01:42 <briantist> going ok.. catching up after getting back from re:Invent
20:02:25 <nitzmahone> Heh, post-conference re-entry is real
20:02:37 <jborean93> has been a while since my last conference
20:02:43 <briantist> it's... a whirlwind yeah
20:02:52 <briantist> my last conf was re:Invent in 2019
20:03:46 <jborean93> #topic open floor
20:03:53 <jborean93> there's nothing on the agenda so keeping it open
20:04:12 <jborean93> I'm hoping to push a new release of a.w and c.w sometime this week, just waiting on some straggling PRs
20:04:24 <briantist> nice
20:04:51 <briantist> I'm trying to convince my coworker to publish a SQL Server focused collection that he's been developing/using internally
20:05:10 <briantist> it's basically ansible wrappers around the `dbatools` module
20:05:22 <jborean93> nice, I know a few people have been asking about MS SQL server stuff
20:06:08 <briantist> it would be cool to get it open sourced and published, and then maybe work on the inclusion criteria too, we'll see how it goes
20:06:16 <briantist> testing is going to be.. a challenge though
20:07:25 <jborean93> yea that is definitely still a pain point, especially on free tier stuff
20:07:43 <nitzmahone> Maybe not so bad as you think- we support tunneled support containers in ansible-test, so a Linux SQL Server container could probably be made to work without too much hassle
20:08:22 <briantist> interesting... haven't heard that term tunneled support containers
20:08:28 <briantist> can you elaborate? how would I use it?
20:08:29 <jborean93> still you need a way to run Ansible and target Windows as well
20:08:44 <nitzmahone> I can't remember if it's totally generic or not, but if the DB creation/population can be scripted reasonably without requiring a huge backup to be restored...
20:09:22 <nitzmahone> Right, but if we did it as a support container ala httptester, it should be "reachable" by default by the Windows target
20:09:36 <briantist> interestingly, we're almost exclusively using these (powershell) modules with pwsh running on the controller (for the time being), via the hacky shell/connection plugin thing I did last year, so testing wise that part is easier.. but we do need to actually test on windows too
20:09:41 <jborean93> yep it is doable but I don't think generic enough yet
20:09:50 <nitzmahone> I can't remember if that got totally generified or not (ie if you could do it without code changes to ansible-test)
20:10:06 <briantist> yeah I don't think that stuff in ansible-test is generic at the moment... it would need to be custom added I think, but still, interesting idea.
20:10:15 <nitzmahone> Yeah, this would be Windows targets against a Linux SQL Server
20:10:46 <jborean93> there's a few stuff here https://github.com/ansible/ansible/tree/devel/test/lib/ansible_test/_internal/commands/integration/cloud
20:11:38 <jborean93> but yea still internal and not public
20:12:24 <briantist> other thing I'd like to do, is maybe convince our company to "support" it by providing self-hosted github runners that we control, which gives us some options for setting up stuff within an isolated network we control
20:12:37 <briantist> we might have more options for services to run against that way
20:12:58 <nitzmahone> The gist is that the test infrastructure sets up an ssh tunnel back to one or more support containers running somewhere else (usually on the controller host) so they're reachable as a network endpoint- the Windows tests use it so we don't have to rely on an internet-hosted httpbin
20:13:22 <jborean93> which was very unreliable and caused lots of test failures
20:13:27 <briantist> I do also have that POC of using public GitHub Windows runners that run WSL1 and have ansible running in there against its host; not the best but it's something
20:14:05 <jborean93> still if the target host is capable of running containers you could just spin up the MSSQL container and target that
20:14:16 <nitzmahone> TBC: the internet-hosted httpbin was unreliable, not the tunneled access ;)
20:14:18 <jborean93> not sure if GHA/other CI providers allow such a thing
20:14:44 <briantist> it does yeah, using that heavily in hashi_vault collection
20:15:13 <briantist> but, I would only be able to run the tests with the pwsh hack that way (linux hosts, linux containers)
20:15:24 <jborean93> or even supports Linux containers on Windows, which AFAIK requires Hyper-V nested virtualisation
20:15:40 <briantist> yeah, that they do not
20:15:46 * jborean93 really needs to get a move on for the local psrp process stuff
20:15:52 <briantist> yes pleaseeeeee
20:15:55 <briantist> 😅
20:15:56 <nitzmahone> Yeah, one way or another, using a canned container for the DB would make that a lot easier- maintaining custom images sucks, and installing the DB on the fly is a hassle and prohibitively expensive
20:16:08 <briantist> agreed
20:16:27 <briantist> some of the things may not be testable with that though; Always-On Availability Groups, etc.
20:16:46 <briantist> so, lots of challenges,  but I think it'd be a very useful collection in any case
20:16:53 <nitzmahone> Oh yeah, just like with eg, the domain stuff, there'll be things that are really hard to test in CI
20:17:05 <nitzmahone> But 80/20 rule and all ;)
20:17:24 <briantist> I like  how some of the recent tests added are just promoting the test instance to a DC and rebooting it to run AD tests, quite nice, and covers a lot
20:17:42 <briantist> can't test mutli-DC stuff or whatever, but, not bad (other than the time taken I guess)
20:17:51 <jborean93> a pity it's an expensive operation :(
20:18:16 <nitzmahone> There's also a lot of things that work when the client is the DC that don't when it's not :(
20:18:16 <jborean93> I was thinking of moving that to it's own group so it only does it once but so far they fit under the time limits
20:18:26 <briantist> right
20:18:28 <nitzmahone> * appear to work
20:18:32 <jborean93> still better than nothing
20:18:58 <nitzmahone> For sure, especially for the domain modules- it's the auth stuff that can give a false sense of security
20:19:55 * nitzmahone goes back to lunching and lurking before my food gets too cold ;)
20:19:58 <briantist> anecdotally though, for the most part.. I run domain modules against DCs rather than from other servers
20:24:13 <jborean93> I've always been unsure how people actually use those modules in the wild. Seems like a dangerous thing to have remote access to a DC like that
20:24:33 <jborean93> i.e. full admin through WSMan rather than the LDAP/ADWS API
20:25:04 <briantist> yeah, only a domain admin works for connecting, so those playbooks are not automated in terms of executing them, only a small subset of human users can run them
20:25:26 <briantist> if I had ever gotten that JEA stuff going, it would've been a real nice mitigation around that
20:25:26 <jborean93> makes a bit more sense
20:27:05 <jborean93> anything else we would like to talk about?
20:27:30 <briantist> nah I'm good
20:27:48 <jborean93> awesome, I'll let us get back onto it
20:27:51 <jborean93> #endmeeting