19:59:59 <nitzmahone> #startmeeting Ansible Windows Working Group
19:59:59 <zodbot> Meeting started Tue Apr 19 19:59:59 2022 UTC.
19:59:59 <zodbot> This meeting is logged and archived in a public location.
19:59:59 <zodbot> The chair is nitzmahone. Information about MeetBot at https://fedoraproject.org/wiki/Zodbot#Meeting_Functions.
19:59:59 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
19:59:59 <zodbot> The meeting name has been set to 'ansible_windows_working_group'
20:00:00 <zodbot> jborean93: Error: Can't start another meeting, one is in progress.
20:00:07 <briantist> FGITW
20:00:07 <nitzmahone> doh
20:00:09 * jborean93 shakes fist at nitz :)
20:00:13 <nitzmahone> lol
20:00:17 <nitzmahone> 1s early
20:00:24 <nitzmahone> #chair jborean93
20:00:25 <zodbot> Current chairs: jborean93 nitzmahone
20:00:28 <nitzmahone> #info agenda https://github.com/ansible/community/issues/644
20:00:34 <nitzmahone> and hey, there's something on it!
20:01:08 <nitzmahone> #topic community.windows new module policy ( https://github.com/ansible/community/issues/644#issuecomment-1102069211 )
20:01:18 <arkanoid> that's for the info. I didn't know about the meeting! I'll leave your space, meanwhile I'll try to understand and learn something new
20:01:20 <briantist> I do agree that guidance should be given to would-be controbutors
20:01:36 <nitzmahone> arkanoid definitely welcome to hang out ;)
20:01:40 <briantist> arkanoid: no worries, this channel is mostly pretty quiet, you came to the right place
20:02:17 <jborean93> yea there are currently 2 new modules, 1 I'm more inclined to merge (the facts/info one) and one I'm less inclined to merge (IIS stuff)
20:02:32 <briantist> imo (not that the maintenance burden falls on me), the dividing line for what to accept should probably come down to what can be reasonably tested
20:02:33 <nitzmahone> Yeah, I'd lean toward option 1 or 2
20:02:42 <jborean93> But there's been a few modules that have been added since it was moved to a collection and I've been pretty arbitrary at what is being accepted or not
20:03:09 <nitzmahone> I'm not even sure that "mirroring something in community.general" is even a decent bar
20:03:49 <briantist> I definitely don't think 1) is a good option tbh.. 2) is I think not quite right; it's a fuzzy definition, and some things that duplicate functionality or try to offer parity can't be tested easily, while something that can be tested well but don't have competing non-windows modules would not be accepted for what seems to be somewhat arbitrary
20:04:03 <nitzmahone> Since the Ansible team isn't (supposed to be) actively maintaining it...
20:04:06 <jborean93> I was mostly trying to figure out a way to state we accept some things but not others which a more clearly defined bar
20:04:16 <briantist> one thing to consider if I may steer the conversation slightly, is that it maybe shouldn't be (just) you supporting it
20:04:37 <jborean93> agreed
20:04:44 <briantist> perhaps we put out a call for additional maintainers and/or replacement maintainers
20:04:52 <nitzmahone> Yep- that's one of the reasons `community` is in the title ;)
20:05:04 <briantist> right, and the collection is pretty important
20:05:46 <jborean93> The trouble is no one else really put up their hands for it. I would also be reluctant to just give merge rights to someone new without some sort of transition period
20:06:22 <nitzmahone> *cough* rstcheck
20:06:26 <nitzmahone> ;)
20:06:47 <briantist> right, I don't know if/when a call when out, but it might be time to ask (again)?
20:07:06 <nitzmahone> Heh, we just had contrib summit- that might've been a good time to ask
20:07:11 <jborean93> right now I'm only just trying to look at the PRs and leave issues as is. The trouble is even PRs can add up to a decent amount of work and potentially increase it more
20:07:17 <nitzmahone> Dunno how many other Windows folks were around though
20:09:19 <briantist> it probably also makes sense to start thinking about breaking up `community.windows` into more specialized collections, like IIS and AD focused things... but it does become even more of an issue of finding maintainers
20:09:38 <nitzmahone> and more places to watch
20:09:57 <nitzmahone> c.g is having the same issues right now (as I'm sure you're aware)
20:10:13 <jborean93> yea I would love to break it up but it would just move the issue to multiple places and add more overhead
20:10:41 <briantist> of course, I'm not suggesting to do it with a single maintainer for all of them
20:10:56 <nitzmahone> Yeah- splitting makes a lot more sense if there are active maintainers for various subject areas (and was kinda the original hope anyway)
20:11:10 <briantist> the bullhorn goes out weekly, so we can start putting out calls
20:11:34 <nitzmahone> Twas why we added support for collection redirection- we *hoped* smaller communities would form around various subject areas and take them over in new collections
20:12:12 <nitzmahone> That's happened in a couple of limited cases, but in general people still seem to like the "grab bag" approach
20:12:30 <nitzmahone> Bullhorn's a good idea
20:12:31 <briantist> well a lot of collections have formed out of c.g at least
20:12:51 <nitzmahone> Yeah, that's definitely been the (minor) success story
20:13:41 <briantist> personally, I'm interested in the `c.w` collection (and in making more Windows collections), but I find myself a little overwhelmed in ansible and non-ansible projects at the moment
20:13:45 <briantist> I think I could start helping with reviews and responding to issues at least, if you all think that would be helpful
20:13:54 <nitzmahone> There are also strange forces at play with the `ansible` community distribution- it's a lot easier to get a module added to an existing collection that's part of that distribution than adding a whole new collection
20:14:22 <nitzmahone> (but even that team is asking questions about the long-term future of that distribution)
20:14:44 <nitzmahone> I don't think anyone will complain about extra help on issue triage ;)
20:15:02 <nitzmahone> Even if it's "yeah, I can reproduce this" or whatever
20:15:33 <nitzmahone> But yeah, don't burn yourself out trying to do too much, either- I think we all struggle with that to some extent
20:18:54 <jborean93> cool, I'll try and have a chat to gundalow and see what he thinks should happen next
20:19:11 <nitzmahone> Yeah, might also want to see how c.g answers the same question
20:19:19 <briantist> ok, sounds good
20:19:19 <nitzmahone> I know they've been talking about various ideas
20:19:56 <nitzmahone> Anything else on that topic jborean93?
20:20:23 <briantist> for your original question, of what to accept, I do think that testing is a good place to start drawing lines.. though. If the tests are present, working, test the right things, and seem like they won't be fragile, I'd be inclined to accept (barring other code issues or whatever)
20:20:43 <nitzmahone> Yeah, that seems like an absolute minimum
20:21:00 <jborean93> Heh both have tests so it will be adding a new IIS module :)
20:21:00 <briantist> but even a well-written contribution that works now is hard to accept if it can't be tested easily. Gray areas are of course changes to existing things liek that (all the AD stuff)
20:21:16 <jborean93> We've actually started testing AD in CI now
20:21:20 <briantist> yeah, I just looked at the IIS one and was going to say: it does look decently tested!
20:21:24 <jborean93> There's a common role to install the AD services
20:21:27 <nitzmahone> My kingdom for AD in a can
20:21:29 <briantist> jborean93: 😍😍😍
20:22:49 <jborean93> apart from that I've got nothing else
20:22:50 <briantist> ok that's awesome... imo that's what can reasoably kickstart breaking out content to a new collection, and that's where extremely knowledgeable SMEs like you two can help the most, is solving tricky base issues like that, that make it easy for contributors to build on
20:23:08 <nitzmahone> It's too bad it takes so long + reboots to get it configured on the fly- I swear the install time for a from-scratch domain has gone up over the years
20:23:48 <jborean93> I've actually set up a Samba domain quite quickly in a container that's probably better to test the AD modules with
20:23:55 <nitzmahone> I swear it was <2min back when I first wrote win_domain
20:24:00 <briantist> we're using GHA + WSL + SQL server in the SQL server collection and runner setup takes ~ 10 minutes 😬
20:24:10 <nitzmahone> I remember running it live in a talk demo
20:24:30 <jborean93> yea promoting the domain is sub 2 minutes, rebooting 8 minutes :)
20:24:48 <briantist> jborean93: I would like to take a look at that sambda container if you have something to link to, not just for this purpose, but for some internal things as well
20:26:06 <nitzmahone> briantist: most of your SQL modules should work identically against SQL Server on Linux in a container, I bet...
20:26:21 <jborean93> sure https://github.com/jborean93/PSOpenAD/blob/main/tools/setup-samba.sh
20:26:40 <nitzmahone> The SQL Linux containers are awesome and basically instantaneous to use
20:26:58 <briantist> nitzmahone they do! and we test both in fact we started with linux testing only, added Windows later to ensure these modules work that way since most ansible usrs will expect to run them on Windows
20:27:15 <nitzmahone> I tried it with the SQL Windows containers as well, but I'm guessing that's a non-starter since you probably need nested virt enabled to use Windows containers in GHA
20:27:40 <nitzmahone> (and IIRC didn't they just quit producing SQL Server Windows containers? Maybe I'm misremembering)
20:28:09 <briantist> Windows containers work on GHA, but according to the notes on this action we use, it actually takes longer to pull the container than to download SQL server and install it: https://github.com/potatoqualitee/mssqlsuite
20:28:16 <nitzmahone> ouch
20:28:33 <briantist> on the linux runners we do use the SQL container though, works great
20:28:46 <jborean93> classic large windows containers
20:29:52 <nitzmahone> Too bad it's not easier to do multi-host stuff in GHA without a lot of special sauce- if they ever make WSL2 work better, you could easily test Windows modules against Linux/container SQL Server, but you'd have to jump through a lot of hoops right now
20:30:05 <nitzmahone> *work better in GHA, I mean
20:30:37 <briantist> right, there's no VinV/nested virtualization support on those runners :-/
20:31:01 <nitzmahone> ... and they're all Server-based IIRC
20:31:08 <nitzmahone> (so WSL2 is "unsupported")
20:31:10 <jborean93> But yea briantist that samba script is what I'm running to replicate the AD stuff. It might not work with the AD modules as they use some SOAP API but it at least provides a pretty feature equivalent LDAP server
20:31:58 <briantist> jborean93: ah yeah I saw that, I was looking at PSOpenAD recently, for some of the admin scripts we have around, as a way to maybe let them work directly on the Macs most folks have here
20:33:06 <nitzmahone> You'd still have to reboot the runner to get it to join a domain though, right?
20:33:17 <nitzmahone> (which I'm guessing is unsupported)
20:33:40 <nitzmahone> or are you just talking about for some of the AD management modules?
20:33:41 <briantist> oh this would be for some work stuff I mean, rebooting GHA runners is not supported
20:33:47 <jborean93> depends on what you need it for
20:34:02 <jborean93> for the AD module technically no as you don't need to actually join the domain to use it
20:34:15 <nitzmahone> I know there's some recovery stuff in the runner project setup that seems like it could be theoretically possible, but even if you could get it to work, I'm not sure you'd want to :D
20:34:17 <briantist> I was briefly looking into AD LDS too as a possible AD-esque/AD-lite thing that could stand in for some testing purposes
20:34:58 <jborean93> But unfortunately the AD modules in PowerShell need MS AD which requires a reboot to setup properly
20:35:11 <jborean93> I can only get away with Samba because I'm testing LDAP
20:35:23 <nitzmahone> I haven't played with that in years, but it seemed like AD LDS required so many exceptions on the client side that it didn't work with anything out of the box and wasn't a suitable stand-in for "real" AD :(
20:35:40 <briantist> they don't necessarily need rel AD, they need AD Web Services or equivalent API
20:35:43 <briantist> but that APi supports AD LDS
20:35:46 <briantist> IIRC
20:35:56 <briantist> I did find this archived repo: https://github.com/larsw/adlds-docker
20:36:06 <briantist> which is pretty much exactly what I had in mind
20:36:07 <nitzmahone> oh my, that sounds like trouble
20:36:10 <jborean93> The only thing I know that has the AD Web Services API is AD itself :)
20:37:19 <briantist> not quite true! I found this and that's what led me down this rabbit hole: https://docs.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2008-R2-and-2008/dd391908(v=ws.10)?redirectedfrom=MSDN
20:38:19 <nitzmahone> Heh, that article dates from about the last time I played with it :D
20:38:30 <briantist> rereading this page, I see it also applies to `Active Directory Database Mounting Tool` and now the really evil wheels are spinning... could we load a "real" AD backup/export into this tool and then use AD cmdlets against it? 🤯
20:39:10 <nitzmahone> till you find out that one piece that they forgot to implement on the web service that still uses LDAP :D
20:39:42 <briantist> well, in the case of AD LDS anyway, the LDAP interface is what's most likely to work correctly :-p
20:39:53 <jborean93> now if only there was some sort of thing that could "contain" these types of roles
20:40:26 <briantist> but I do think this might hold promise as a potential testing/CI target, for some subset of operations, and is much more lightweight (it's right in the name!)
20:40:38 <briantist> that archived repo shows a container being built with it...
20:42:23 <jborean93> definitely something to think about, there was talks about potentially making the domain stuff supported but I haven't committed anything to that yet :)
20:42:43 <briantist> got it
20:43:18 <nitzmahone> Yeah, doing the domain stuff "properly" with a real DC would likely require some changes to ansible-test that we don't have time to make
20:44:07 <nitzmahone> We've talked about it for years, and even sketched it out, but getting it working quickly enough to not explode our CI testing time would also require maintaining a pre-promoted DC image
20:44:13 <jborean93> I've got nothing else to add, I'll have to talk to gundalow to see what the future holds for c.w as right now even just trying to review the PRs there is time consuming
20:44:32 <nitzmahone> No new topics from me
20:45:00 <briantist> alright, well I'll (cautiously) throw my hat in as willing to put some time and effort into Windows stuff
20:45:14 <nitzmahone> thanks for whatever you're willing to do!
20:45:32 <jborean93> yea thanks but please don't feel obliged, I know you do a lot already
20:45:33 <briantist> if it were a year ago or so I'd probably be jumping at it but I got real busy last 6 months or so
20:46:09 <briantist> speaking of which making good progress on CcgVault, got a lot more tests up, and a README (quick plug: https://github.com/briantist/CcgVault )
20:46:30 <jborean93> nice
20:46:46 <jborean93> I've yet to really dip my toes too deeply into Windows containers
20:47:09 <jborean93> I have been considering moving my main dev box to Windows though
20:47:46 <nitzmahone> I've actually really been enjoying my little Surface Pro X- fired up WSL2 and an ansible dev env
20:47:55 <briantist> I've barely touched them tbh.. but there's a whole class of production workloads I can see going into them, as long as we can maintain domain auth/connectivity, so that's what led me to this project
20:48:25 <jborean93> The small issues I have are starting to bug me a lot on Linux so it's getting real tempting
20:48:31 <nitzmahone> Bought it as a really expensive sheet music folder, but been fun to screw around with other things on such a crazy portable platform. Now we just need arm64 ansible-test containers :D
20:48:35 <briantist> can't say enough good things about WSL2, using it with vscode with 👩‍🍳👌
20:50:09 <nitzmahone> I also tried Ansible on the nogil experimental interpreter for a few minutes while I was blocked on something last week- once I got past the OpenSSL stuff segfaulting the vault imports at startup, it worked great
20:51:36 <briantist> interesting
20:51:52 <briantist> hadn't heard of this, do not know enough about python internals to have heard of GIL
20:52:03 <nitzmahone> Heh, just pretend I never said anything :D
20:52:16 <briantist> done!
20:52:17 <nitzmahone> (this is a big part of why Ansible relies on `fork()` so heavily)
20:52:32 <nitzmahone> Otherwise we'd thread the crap out of things
20:52:44 <nitzmahone> So maybe someday
20:53:08 <nitzmahone> Welp, if nothing else, we'll close until next week...
20:53:18 <nitzmahone> Thanks all!
20:53:20 <nitzmahone> #endmeeting