20:00:02 <nitzmahone> #startmeeting Ansible Windows Working Group
20:00:02 <zodbot> Meeting started Tue Nov 16 20:00:02 2021 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 https://fedoraproject.org/wiki/Zodbot#Meeting_Functions.
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:23 <nitzmahone> #info agenda https://github.com/ansible/community/issues/581
20:01:18 <nitzmahone> #topic https://github.com/ansible/community/issues/581#issuecomment-969356356 (hybrid DSC)
20:02:15 <nitzmahone> Welcome MKletz! You wanna intro the topic? Might be just me today- I think Jordan's sleeping off a headache or something
20:02:24 <Mkletz> ahh ok
20:03:00 <Mkletz> yeah so it looks like this issue basically boils down to the fact that CIM doesn't display composite resources since they aren't really resources
20:03:27 <Mkletz> for those unfamiliar these are configurations being "bundled" and masqueraded as resources for use in other DSC configurations
20:03:31 <Mkletz> let me find an example
20:03:52 <Mkletz> oh past me linked one on the issue
20:03:54 <Mkletz> https://github.com/dsccommunity/xSystemSecurity/blob/master/source/DSCResources/xIEEsc/xIEEsc.schema.psm1
20:04:44 <Mkletz> When these are handled natively they are actually expanded within the mof
20:04:58 <Mkletz> and the individual resources are executed on
20:05:31 <Mkletz> since win_dsc uses invoke-dscresource the mof file is bypassed entirely so it just sees an invalid resource being referenced
20:05:44 <Mkletz> I hope that makes sense?
20:05:55 <nitzmahone> Yep!
20:06:51 <nitzmahone> Not sure what all was still needing discussion- we're in principle good with this idea
20:06:56 <Mkletz> MS is working on some changes to this process but they will not be retroactively ported to 5.1 which I would imagine is what the majority of win_dsc users are using
20:07:26 <nitzmahone> Yeah, until Windows actually ships with a newer version of PS as the default, 5.1 is kinda the state of the art for this stuff
20:07:44 <Mkletz> I think there was some discussion around making this a separate module from win_dsc
20:08:36 <nitzmahone> I could see that, at least for awhile- especially since IIRC it adds some new required deps, right?
20:08:56 <Mkletz> the proof of concept I had working really doesn't share much of any code with win_dsc since it's functionally different
20:09:14 <Mkletz> the only downside is I think this might be confusing for the user
20:09:48 <nitzmahone> The tricky part for us is always the support aspect
20:09:53 <briantist> hey folks, lost track of time
20:10:00 <nitzmahone> Hey briantist!
20:10:16 <Mkletz> yeah i think it could functionally be done it's just not going to be very user friendly
20:10:18 <Mkletz> hi!
20:11:06 <nitzmahone> Since win_dsc is an officially supported module, we basically have to be willing to adopt responsibility for the code
20:11:16 <nitzmahone> (ie any changes that are made to it)
20:11:39 <nitzmahone> So doing it in a community collection and letting it get battle-tested a bit makes us more comfortable doing so
20:12:39 <Mkletz> that makes sense, I'm happy to work on it just not sure what direction to go down
20:12:53 <Mkletz> I've actually started working at RedHat since I opened that issue if that helps with the process at all
20:12:58 <nitzmahone> Maybe something like a new community.windows module `win_dsc_composite` or ?
20:13:17 <Mkletz> yeah I think that's fine
20:13:43 <Mkletz> long term I think they should live together for ease of use but keeping it separate until it's fleshed out is a good idea
20:14:03 <nitzmahone> If you can track the `win_dsc` module UI, and the intent is that the module would completely supersede `win_dsc` at some point for functionality, then we could just work toward swapping it out at some point
20:14:08 <briantist> since not much code is shared, new module probably makes sense. I wonder if some of the dynamic option handling and verbose output stuff could move to a module_util
20:15:14 <Mkletz> that I'm not super sure on, I've got a lot of powershell dev under my belt but not a ton of ansible
20:16:38 <Mkletz> I just ran into this issue trying to help the ops team at my previous employer use some DSC resources I wrote. I'm happy to go in whatever direction you'd like.
20:17:08 <nitzmahone> So do you have an Ansible module wrapped around the composite invoker yet at all?
20:17:17 <Mkletz> I do not
20:17:34 <Mkletz> I can put some time into that
20:17:42 <nitzmahone> Maybe that'd be step 1- just take the existing one and brain-transplant your invocation into it
20:17:48 <Mkletz> kk
20:18:06 <Mkletz> I'm not super happy with the implementation here
20:18:07 <Mkletz> https://github.com/MKletz/DSCTools/blob/main/src/DSCTools/functions/public/New-DscMof.ps1
20:18:25 <Mkletz> now that psdesiredstateconfiguration is separated out I want to try and find a more secure way that string templating script blocks
20:18:35 <nitzmahone> If it turns out to be super simple and something that we could just auto-detect or add a switch to, maybe putting into the existing module *would* be OK
20:18:52 <Mkletz> there is a fairly simple way to detect it
20:19:04 <nitzmahone> So if you don't want to start from scratch, maybe try it that way and see how it looks
20:19:06 <Mkletz> would end up needing some refactoring of win_dsc but that's to be expoected
20:19:31 <Mkletz> ok will do
20:20:25 <nitzmahone> Because yeah, briantist's point is valid that a lot of the parameter translation and stuff should be the same
20:20:39 <Mkletz> yeah a lot of that would translate iirc
20:20:51 <Mkletz> it's just the actual invocation logic is totally new
20:21:24 <Mkletz> I think it can be refactored to just have a single invocation point at the end and just have logic determine how it gets that it needs to invoke
20:21:34 <nitzmahone> So yeah, if you want to start with a PR that just bolts it into the existing module (esp if there's an reliable auto-detect of "we need the composite code path"), then maybe it's not so bad to just keep it all in one
20:21:35 <Mkletz> what it needs to*
20:21:54 <Mkletz> sounds good
20:21:58 <nitzmahone> #action MKletz to PR win_dsc composite resource support
20:22:32 <nitzmahone> Cool- thanks for working on it!
20:22:53 <nitzmahone> #topic open floor
20:23:07 <Mkletz> np! excited to see this get added. Mostly because my largest personal project is all composite resources and I'd love to see it get more adoption
20:23:17 <nitzmahone> I'll wait for a few minutes for any new topics before closing the meeting...
20:23:29 <briantist> this is awesome stuff, thanks Mkletz !
20:23:53 <Mkletz> thank you
20:28:06 <nitzmahone> Thanks all- no meeting next week due to US holiday, so two weeks!
20:28:16 <nitzmahone> Oh wait, NM
20:28:27 <nitzmahone> Derp, it's Tuesday- next week as nromal
20:28:29 <nitzmahone> *normal
20:28:52 <nitzmahone> 'til next week!
20:28:56 <nitzmahone> #endmeeting