20:00:00 <nitzmahone> #startmeeting Ansible Windows Working Group 20:00:00 <zodbot> Meeting started Tue May 2 20:00:00 2023 UTC. 20:00:00 <zodbot> This meeting is logged and archived in a public location. 20:00:00 <zodbot> The chair is nitzmahone. Information about MeetBot at https://fedoraproject.org/wiki/Zodbot#Meeting_Functions. 20:00:00 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic. 20:00:00 <zodbot> The meeting name has been set to 'ansible_windows_working_group' 20:00:02 <nitzmahone> bam 20:00:06 <nitzmahone> #chair jborean93 20:00:06 <zodbot> Current chairs: jborean93 nitzmahone 20:00:10 <jborean93> yo 20:00:16 <nitzmahone> #info agenda at https://github.com/ansible/community/issues/682 20:00:21 <nitzmahone> nothing new 20:00:24 <nitzmahone> #topic open floor 20:00:34 <nitzmahone> I'm guessing jborean93 has a topic ;) 20:01:34 <jborean93> `ansible.windows 1.14.0`, `community.windows 1.13.0`, and `microsoft.ad 1.1.0` were released yesterday 20:01:49 <jborean93> gotta check if a.w and m.a were approved in AH but I believe they were 20:01:52 <nitzmahone> 🎉 20:02:24 * nitzmahone is curious how much enforcement there is on the approval/certification stuff that actually applies to the Windows collections 20:02:37 <jborean93> I've never been pushed back 20:02:56 <jborean93> I think if the general import was successful (meta/runtime.yml and valid MANIFEST.json) then they are good to approve it 20:03:21 <bcoca> jborean93: i think everyone trusts you to actually run the tests 20:03:42 <nitzmahone> that's their first mistake ;) 20:04:04 * jborean93 laughs manically 20:04:19 <nitzmahone> lol 20:04:19 <jborean93> yep they are live in AH now 20:04:23 <nitzmahone> noice 20:04:38 <nitzmahone> well, if no new topics in 1min, we'll wrap it up[ 20:04:51 <jborean93> I'm hoping to clean up my LAPS decryption code into a standalone module so I can also add support for that in the ldap inventory plugin but that's most likely going to be slow going 20:05:01 <jborean93> apart from that, I'm good 20:05:26 <nitzmahone> Yeah, that stuff is a little scary since so much of it seems to be undocumented behavior "between the lines" in the spec :( 20:05:48 <jborean93> Half seems documented, the other half not so much 20:06:06 <nitzmahone> (ie, seems like a good candidate for a community "best-effort" support model, at least for awhile ;) ) 20:06:12 <jborean93> yep definitely 20:06:24 <nitzmahone> "hey, here's a thing that might work or might kick your dog, have fun" 20:07:07 <nitzmahone> If MS is willing to clarify the spec for some of that stuff, I'd feel a lot better about transitioning to a Capital S Support model 20:08:23 <nitzmahone> But TMK nobody's asked yet anyway- especially as it transitions to an in-box feature though, I bet it will happen 20:08:35 <nitzmahone> (on the WIndows side I mean) 20:09:55 <jborean93> Yea it's definitely murky. I feel a bit more confident the behaviour is more set in stone. it would be a herculean effort to backport a different decryption setup to Windows. Not that it's not possible but still improbable in my eyes 20:13:22 <nitzmahone> Yeah- the part of that that worries me the most is around the structure "probing" that's typically used to support that kind of behavior that we're almost certainly missing (basically how the Windows layers deal with discovering the runtime "shape" of polymorphic struct buffers at runtime by sniffing particular bits) 20:14:17 <jborean93> There is only 1 field which is somewhat unknown and dependent on flags. I've sent an email to dochelp to clarify because they document it as a bool field when in reality there is another flag present in production today 20:14:30 <nitzmahone> yep :( 20:14:41 <nitzmahone> Hopefully they'll be forthcoming with those details 20:14:47 <jborean93> I do agree that it wouldn't be capital S supported until enough time has passed and we are confident things are correct 20:15:27 <nitzmahone> Welp, might as well wrap up until next time... TTYL! 20:15:32 <nitzmahone> #endmeeting