ansible_windows_working_group
LOGS
20:00:01 <nitzmahone> #startmeeting Ansible Windows Working Group
20:00:01 <zodbot> Meeting started Tue Jan  4 20:00:01 2022 UTC.
20:00:01 <zodbot> This meeting is logged and archived in a public location.
20:00:01 <zodbot> The chair is nitzmahone. 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:07 <nitzmahone> bah
20:00:10 <nitzmahone> #chair jborean93
20:00:10 <zodbot> Current chairs: jborean93 nitzmahone
20:00:12 <briantist> yo
20:00:18 <nitzmahone> hey hey
20:00:30 <nitzmahone> #info agenda https://github.com/ansible/community/issues/644
20:00:37 <nitzmahone> nothing new for today so
20:00:42 <nitzmahone> #topic open floor
20:00:49 * jborean93 waves
20:01:47 <briantist> windows (not ansible) related: I'm dealing with an annoying issue trying to write a managed (dotnet) out-of-process COM server
20:02:07 * jborean93 runs away from COM
20:02:19 <nitzmahone> Heh, I did that many years ago
20:02:27 <briantist> even with no params and no code other than `return 0;`, it's throwing "remote procedure call failed"
20:02:34 <nitzmahone> Are you doing it with COM+, or just naked?
20:03:04 <briantist> the whole thing is related to trying to write a plugin for the container credential guard, to support running Windows containers that identify on the network as a gMSA, without joining the container host to the domain
20:03:27 <nitzmahone> I don't think I was able to get it working just using COM interop- I had to manually create all the registration code
20:03:38 <briantist> nitzmahone: I'm actually working off the dotnet core sample project that's specifically for OOP COM
20:03:54 <briantist> https://github.com/dotnet/samples/tree/main/core/extensions/OutOfProcCOM
20:04:05 <nitzmahone> Oh, they didn't have any such thing back in the day (this was like .NET 1.1/2.0 in the early 2000s :D )
20:04:41 <briantist> I had it all working (from a sample client, not from CCG) with an in-proc COM server before realizing it wasn't working with CCG because it specifically runs the plugin OOP
20:04:43 <jborean93> don't gMSAs need to be "installed" on the host in question meaning they need to be domain joined?
20:05:03 <briantist> technically only MSAs (the non-group kind) need to be installed
20:05:19 <briantist> gMSAs have a property that lists the security principals that are allowed to retrieve its managed password
20:05:34 <jborean93> interesting, I thought it still needed to be installed/registered on the host in question but makes sense
20:06:18 <nitzmahone> I'm actually curious why a COM+ surrogate with an in-proc server wouldn't fit the bill...
20:06:27 <briantist> the `Install-ADServiceAccount` "works" with gMSAs but it basically just confirms whether the computer in question is has permission, it doesn't do any actual setup like it does with MSAs
20:06:51 <nitzmahone> Sounds like you mostly had it working that way
20:06:57 <briantist> I suppose they want some kind of isolation and explicitly run it OOP? not certain
20:07:13 <nitzmahone> COM+ surrogate is still OOP, you just don't write the server process
20:07:20 <briantist> anyway my mistake was not using their sample directly first before replacing their function with mine, I guess
20:08:24 <briantist> there's precious little info from MS on it, other than this C++ sample and the interface definition: https://docs.microsoft.com/en-us/windows/win32/api/ccgplugins/nf-ccgplugins-iccgdomainauthcredentials-getpasswordcredentials
20:08:37 <briantist> anyway, I'll keep plugging away at it
20:08:55 <briantist> I do have an update that IS ansible related and might be of interest
20:09:41 <jborean93> fire away
20:09:52 <briantist> the docs build process I have for `community.hashi_vault`, that determines if a PR has docs changes and if so, renders them puts a nice comment on the PR, has been re-written with shared GitHub actions and reusable workflows, so it can now be consumed easily by other collections
20:10:00 <briantist> parameterized, customizable, etc.
20:10:05 <nitzmahone> nice
20:10:43 <briantist> I know currently in the `docs/` folder of the Windows collections we have RST files
20:11:33 <briantist> with this stuff we could also automate that to be rendered HTML if that's preferable. And we could enable this PR feedback easily as well.
20:12:03 <briantist> added it to `commmunity.docker` as a demonstration: https://github.com/ansible-collections/community.docker/blob/main/.github/workflows/docs-pr.yml
20:12:19 <briantist> that's with all defaults except for the PR comment messages
20:12:24 <jborean93> so does it build module docs from the .py files?
20:12:43 <briantist> yes, modules, plugins, docsite (if one exists for the collection)
20:13:02 <briantist> I publish the main branch collection docs automatically with it too: https://community-hashi-vault-main.surge.sh/
20:13:21 <jborean93> might be good to get rid of that collection_prep script with something better
20:13:56 <briantist> where is that script?
20:14:16 <jborean93> https://github.com/ansible-network/collection_prep
20:14:34 <nitzmahone> Yeah, I still wish we had a better solution for publishing non-plugin-docs from collections on galaxy or something- it's been kicked around, but it always pretty quickly ends up devolving into a really crappy version of RTD :D
20:15:09 <jborean93> it'
20:15:19 <jborean93> it's a pity we need to support nested tables for module options
20:15:34 <jborean93> I had an okish markdown templater as a POC but fell flat when it came to that part
20:15:48 <briantist> do you run that script manually then when prepping to release?
20:16:06 <jborean93> yea
20:16:47 <nitzmahone> IIRC they actually recently reformatted to kill the nested tables
20:17:02 <briantist> heh yeah was just going to mention that re: tables
20:17:25 <nitzmahone> It's not perfect, but it at least gets the embedded HTML crap out of the way that we used to do in the markdown
20:17:27 <jborean93> yea sorry I meant something like nested table support
20:17:45 <jborean93> and IIRC even GitHub's markdown formatter didn't allow embedded HTML
20:17:55 <nitzmahone> Wasn't sure if that change had been merged or not, but I looked it over and +1'd it
20:18:14 <briantist> I think this docs build stuff could fairly easily be set up so that when you do a release (push a tag), it could build the site and commit the rendered site to `docs/` or whatever
20:18:39 <nitzmahone> self-committing builds though...
20:18:46 <briantist> heh, yeah...
20:19:01 <briantist> but if you're interested in the PR feedback part at least (which is pretty helpful imo) I could put up a PR to implement that
20:19:02 * nitzmahone has been burned on that road way too many times
20:20:02 <briantist> might wait until we move the components to their own repo and out of mine, just for ease of reference: https://github.com/ansible-community/community-topics/issues/59
20:20:33 <jborean93> Might be something to consider if we ever start adding in extra docs and not just the plugin stuff. In reality I need a check that tells people to stop editing the rsts directly and to make the changes on the .py fikes
20:21:16 <briantist> oh I could whip that up pretty easily actually (though that'd be unrelated to the docs build stuff haha)
20:22:20 <briantist> anyway when this stuff settles a little and gets into its own repo, and maybe a few more collections use it, we can discuss again
20:25:54 <nitzmahone> Sounds good
20:25:59 <nitzmahone> Anything else burning this week?
20:26:14 <briantist> nope
20:26:33 <nitzmahone> I'll close in 2min if nothing pops up
20:28:16 <nitzmahone> OK, til next week- thanks all!
20:28:19 <nitzmahone> #endmeeting