initial engine draft

[rdbartram]

No description provided.

[gaelcolas]

We should make sure we decouple the DSC Compilation from the invocation.
The Compilation and the Configuration keyword are parts of PowerShell and partly from the PSDesiredStateConfiguration.psm1 module.
I'm pushing for the latter to be Open Sourced, and for some work to be done by the Config team to allow decoupling compilation from Format (so that we could access in-memory representation of the resource graph).
We'll see where that goes, but Open Sourcing the PSDesiredStateConfiguration module should be possible in the mid-future (~6months kind of timeframe)

[rdbartram]

you are right here. That should be another RFC. My thinking here was because I wanted to adjust the schema that we would need a new compiler. But with hinsight, supporting existing MOFs is a must. Doesn't mean we can't support newer features but thats out of scope for the invocation.

[gaelcolas]

Yes, we should abstract what this use from the file format for future-proofing. Support MOF for now (as you do with your Compare-MOF) but enable the serialization to be something else (like JSON).

[rdbartram]

As mentioned above, supporting existing MOFs is a must

[gaelcolas]

Yes, although there's the downside of some missing bits in the current implementation:

• missing PsDscRunAsCredential support (because windows & Linux have different impersonation models)
• DSC (and resources) still relying on CIM but CIM cmdlets not existing on Linux

There are ways to work around this (probably quickly mentioned in the RFC comments), and ideally this should filter through to PSDesiredStateConfiguration.psm1 to keep it consistent with Implementations.

We should, for instance, create a command proxy for Invoke-DscResource that supports Invoke-DscResourceAs and if on windows and PsDscRunAsCredential is set, use a runspace and impersonate the provided user. If on Linux and PsDscRunAsCredential is set, start a PS Job as that user.

[rdbartram]

I like the idea of an Invoke-DscResourceAs. I will add this to the RFC.

I haven't tested it yet (just breifly looked at the DSC Linux repo), but since DSC resources are just python scripts. We could import them and run the Get/test/set_Marshall commands.

[gaelcolas]

Invoke-DscResource in PS7 only supports PowerShell type of resource (MOF & Classes), and platforms (as long as the resource works on that platform).
I think we should not try to implement our own Python resource 'invocation', it will eventually be done by Invoke-DscResource, if there's value (and that should be open sourced at some point anyway). Invoke-DscResourceAs should just be a proxy command that adds the PsDscRunAsCredential support, by abstracting the underlying impersonation model (either with threadJobs & Impersonation in Windows or PS Jobs in Unix/Linux).

[gaelcolas]

I'm not 100% sure I understand what you describe.
Maybe we'll have call to clarify.
Only remark here is that we should support/keep a default execution model similar to what DSC in Windows PS 5.1 has, so that it's easier for users to transition to it.

[rdbartram]

it was just my way of describing how I would try to overcome the serial nature by which DSC executes today. I will try to reword, but we can also have a call to describe

[gaelcolas]

We should support configuration serialized as MOF using the existing capabilities (supported in Windows PS 5.1, PS7-Preview.4+ and I think PS 6.2.1).

I don't think that LCM should support Windows PowerShell (as long as MOF are supported and apply to a consistent result).

I think we should clarify a bit the scope of this effort to start with, and in what order we'll do it.

1. try to provide the "functionalities" of the previous LCM (similar & consistent, not necessarily like for like).
2. Try to make the functionalities available as a service communicating via an API (whether to support old Pull Server is a question we can discuss later)
3. Provide the basics of a central server that can communicate and manage that service

My point is the core functionalities can and should be done in a most generic way, so that third parties (AWS, Chef, Puppet, Ansible & others) can also rely on them should they wish to do so.

The service wrapper is something that would be specific to the solution. Third parties would use their own agent, so it will differ.

At last, the central server should probably integrate other functionalities (by that I mean be extensible), that's clearly out of scope for now.

[rdbartram]

I'm happy to drop WinPS support, so that fine for me.

This is just the RFC pertaining to the engine. There are so many feature I would like to implement here, not only standard API access to provide better integration.

The scope for me is as you've mentioned. I will add it to the PR but just for santities sake. I want to keep as many of the functional features that we have today. i.e. pull server interop, both file and http. the three modes, apply only, apply and monitor and apply and autocorrect. It would be great to have cross platform support with equal feature sets and finally increased performance not only by means of parallelism

[gaelcolas]

I would really not bother invoking Python resources there.
If there's value, let's wait for Invoke-DscResource to either do it for us or be open sourced so we can add the functionality.

[gaelcolas]

It might be just about semantics or implementation details, but I think aiming too early for a PowerShell based LCM is the wrong first step. By that, I mean the scope is probably too broad.
The way I'd see the architecture of this is that we first create a module that depends on the PSDesiredStateConfiguration.psm1 (the one that ships with PS7).
This module would provide the functions that an LCM requires, but not the service wrapping a standalone service would need.
So that module would expose commands such as:

• Invoke-DscResourceAs (proxy command to support Invoking a resource in a different user context)
• Resource Graph De-serialisation (from MOF to in-memory resource graph)
• Getting Resource properties' type information (i.e. for validation)
• The (basic) logic to process the Resource Graph and hand off to Invoke-DscResourceAs
• Decrypts PSCredentials from Serialized representation
• Allow runtime retrieval of secrets, without overlapping with (but leveraging) Secrets management RFC
• Pull required modules from gallery (most-likely leveraging PSGet, or a configurable option to use something else, like another module)
• Handle Logging, tracing, and debugging features

I might be missing a couple but that's a good base. This module would only provide the features, and would require "scripts" or something else to invoke it.
The goal of doing so, is that module would be a common base that third parties could rely on and contribute to: Chef, Puppet, Ansible, AWS, and so on...

Then, in a second step (and its own RFC), we'd need to build the actual LCM: A service that communicates with a central server (exposes an API and has a communication protocol), can be configured, handles reporting, registration, maintenance windows, different modes, scheduling.

The idea is mainly to separate step 1 and step 2, although realistically they won't be done completely sequentially, but in parallel.
The MVP for the second step, could be a simple schedule tasks initially with very basic functionality to call the functions of the module created in step 1.

Hope that makes sense.