Make it explicit here it's only PowerShell class based DSC resources

Make explicit that compilation results in JSON instead of MOF

Although i appreciate the shout-out to Gael, I'm not sure this paragraph belongs here. Perhaps an acknowledgement section in the back of the RFC would be more appropriate.
I think what we should have here is a description of the behavior that we will be supplying.

The point here was to connect it back to the Invoke-DscResource work

I'm still not clear on what I need to do here. Do we have documentation to which we can refer for enabling this.

This is confusing to me as well. If I'm understanding correctly this would be the new workflow:

1. Write out a configuration in PowerShell (using the Configure keyword), same as previous versions.
2. Export the configuration to JSON.
3. Use a custom script or third-party tool to parse the JSON and then run the DSC resource modules using Invoke-DscResource.

I think step 3 is where my disconnect is. Could we have a built in command that would would parse the JSON file and run the DSC resources? This would at least give us the base functionality, which we could then extend if needed.

AFAIK since there is no schema, I think it wont be an easy thig to provide a built-in cmdlet for that.

Well there doesn’t need to be a strict schema. The configuration file is basically just key value pairs. All DSC resources have get, test, and set methods you use to compare with the values in the config. That’s what the original LCM did. Granted it wouldn’t be very hard to write a script to reproduce that functionality, but I feel like by not having this built in, it will prevent a lot of non-programmers from using DSC. I mean the original point of DSC was so non-programmers could easily build up configurations. If you really strip things down to basics, we don’t even really need DSC resources. We could just write PowerShell scripts that apply the settings we want directly.

yep, I agree

A small clarification about ...

If I'm understanding correctly this would be the new workflow:
Write out a configuration in PowerShell (using the Configure keyword), same as previous versions.
Export the configuration to JSON.
Use a custom script or third-party tool to parse the JSON and then run the DSC resource modules using Invoke-DscResource.

This is one option; that is if the user decides to go through "configuration ps1" -> JSON (which used to be MOF) -> third-party tool to parse the JSON and then do whatever it needs route.

Another (faster) option is to just call Invoke-DscResource directly - see examples in this link.

I understand. My main point was that one of the original benefits of DSC was that people without a lot of programming or scripting experience could still write configurations. Having to manually call the resources with Invoke-DscResource, or build a script to replace the functionality of the LCM, just seems like a bit of a step back. I like the idea of having it open for third-parties to build on, but it feels like we are loosing some base functionality in the process. Anyway, that’s just my 2 cents.

I kinda agree with you, but we lost that already from 5.1.
This is actually "bringing back" functionality, so I see it as a good (re)start.
I hope that in due time we'll get closer to what we can do with 5.1, whether it's with a third party agent, from the community or why not using Guest Config...

Hey,

I like the discussion so far. But I must agree with @kgraves83 a lot. By removing the LCM completely, it will be hard for people to manage DSC. I know in the RFC it's talking about: integrate with existing configuration agents like Ansible, Chef, Puppet, Azure Policy Guest Configuration, and other popular configuration solutions. But I don't think that is a good solution for companies, who use the old DSC. Because you can just run Start-DSCConfiguration on any machine in a well-configured environment and the party can start.

With the new solution, you must first find the current json configurations for the machine. Then you must take a look into the configuration and install all required modules on the target machine. (normally DSC would pull them from the pullserver) And then run them on each target machine. And the tool to manage all of this is handcrafted by an admin. Oh and don't forget the monitoring feature. That must be also done manually with the new solution if I understand it right.

I mean it's a good starting point to implement first the logic of "how a configuration is parsed and can be used". But this RFC shouldn't forget the management of many configurations for a big DSC environment. The popular configuration solutions had for me two downsides:

• Ansibel and Chef needs a Linux Host
• Azure Policy Guest Configuration works only if the company uses azure

So in a completely Windows based environment that is disconnected, there is no solution. I really want to see something like a basic tooling for those use cases. I think the idea of something like a LCM as agent isn't a bad idea. I think DSC need something like that to work well. The downsides of not having it are to big. Maybe this is the wrong RFC for that discussion , but I think that is important.

I really wish to see something like LCM 2.0 or something like that.

Worth noting here: From a CM vendor perspective (/me waves in Puppet developer) while we could support calling a config script from within the CM tool, they already have a DSL (or yaml def in the case of Ansible) where users are defining their full configuration info - even telling DSC to handle the JSON blob of configs would require writing some DSL - we're probably going to continue to support and recommend our integration which is built on top of Invoke-DscResource.

For Puppet specifically, we've been doing a lot of work over the last year to build a strong translation layer between the API surface of DSC Resources and Puppet so you can consume DSC Resources just like any other Puppet resource - with the full suite of support sugar from our VSCode extension, compile time validation, etc.

I think that experience is going to be better for our users than a new Puppet resource which allows you to specify a JSON blob (as a herestring or path to the blob) and is only able to do change reporting based on the entire blob or (assuming property-by-property reporting gets implemented at the same time as these other changes) needs custom logic to surface DSC's internal change reporting.

I suspect but do not know that the situation for other CM vendors is similar from an integration perspective.

The more important need for us is to make sure we can fully map a DSC Resource's surface from Get-DscResource since we won't be able to map it via inspecting the CIM instances anymore (especially whatever we're calling nested CIM instances now that they won't be CIM instances).

sort of burying the lead here. I think it will be better to lead with the JSON config and use the earlier sentences as rational for the change.

how? Do we have a pointer for folks to follow to construct this?

i assume that someone could build their own python based resources if they also build an agent for them.

No, as use of DSC Resources is via the *-DscResource cmdlets, those only understand PowerShell classes, so unless they transcompile to a PowerShell class, then other languages are not currently planned to be supported

I remember the File/Directory resource is written in C++ (WMI provider), so it's no longer supported with the new DSC, right? If so, the example below may need to change as it's still using File resource.

That is correct, the File resource was just used as an example of configuration file format

is this useful if we're not building MOF?

Fix ordering of instances to match mof example

I don't think the backslashes need to be double escaped here. once for JSON encoding, but that is all it should need

Rename PullServer to some other computer name to avoid confusion with pull server

it might be useful to have examples for invoke-dscresource or the entire chain of agent setup, invocation, result.

removed from what?

It's not very clear to me what this mean as I cannot map this statement to the above demo.

this is a pretty strong argument to drop the MOF equivalent above.

Why is there no C# class-based DSC resource?

It's certainly something that can be supported later if there is a need for it. Initially, we're targeting making it simpler and PowerShell class-based DSC resource development model already exists while we'd have to create one for C#.

Please correct me if I'm wrong but there really shouldn't be much additional work required supporting PowerShell and C# class-based resources. If the PowerShell class is being imported as a dynamic assembly, DSC can use the same logic to identify C# and PowerShell DSC resources.

You are right, theoretically there really shouldn't be much additional work to support C# resources, however things get complex when we get into details because the existing code is rather difficult for historical reasons.
For example, for resource enumeration (Get-DscResource) current code does Not actually import PowerShell class as a dynamic assembly. It sends psm1 with class to PS parser, retrieves AST and then traverses it looking for DSC attributes (e.g. DscResourceAttribute) and constructing internal resource metadata descriptions that are later (and Not in a straightforward way) returned as Get-DscResource results. The class module is actually imported (in the usual PS sense) only at Invoke-DscResource stage.

If it is difficult to add enhancements to the existing code base, then maybe its time to look at redesigning/refactoring while these major DSC changes are being proposed. As for Get-DscResource not importing the C# assembly until Invoke-DscResource is called, I believe that could be solved with a MetadataLoadContext as described in PowerShell/PowerShell#6653.

That is good info about MetadataLoadContext ; thank you.

totally agree - is this sort of an open switch or do you have ideas/suggestions for this?

yay!

Link to subsystem RFC once published

although not really needed here - is there an RFC for enabling custom keywords?

as an aside, we need to be sure that a schema for the JSON is published or otherwise available for a good authoring experience.

I see an opportunity for a tool or VSCode plugin to generate a schema on the fly from available resources. Based on the example json earlier in the RFC, the schema will end up very generic and not able to offer more than basic structural validation. An auto generated schema can offer a much stronger validation and auto complete for resource properties.