gaelcolas commented 1 year ago

Summary of the new feature / enhancement

I'm not trying to be the party pooper, but having no context, I think this could do with some clarifications. Also, the name is not helping, it adds to the confusion and probably should be changed ASAP (before Microsoft teams create their own semantic that is unteachable or too far away from existing practices and tools once released). I'm raising this as an issue (for lack of discussions) as it's not directly related to the PRs. Feel free to enable discussions and move it there, I can create relevant issues as needed after an initial back and forth. I'll review the PRs separately, once I understand the purpose "enough".

1. Naming issue and missing context

It may seem too early to "care about trivial things such as name", but I think we need to be careful with the whole semantic here, and start being precise.

DSC is already a loaded term (and DSCv3 already refers to PSDSCv3), and the current reasoning transpiring from what I've read so far is yet another take on the good old Configuration Management paradigms... Moreover, assuming I understand the thinking thus far, this would sit above PowerShell, so it's more of a meta-resource enacter, so let me try to define what I read is the intention, and please correct me…

Note: configuration already refers to the PSDSC keyword config is already used as a utility on Unix-like OSes.

Proposed technical implementation details (optional)

2. What is this repo about?

Create a utility (later refered as "the tool", think CLI to start with) built to:

Enact: Converge towards a state defined as a policy regardless of the current state (aka "Make it so" from declarative document).
Apply: Set more or less bluntly (relying on the resource) without validating state.
Validate: Test whether the current state is compliant with what's desired.
Query: Gather the current state of a configuration item, uniquely referenced for a given scope (to be defined later)

3. Why do we need this?

The WinGet folks were asked to "define a state of installed stuff and converge", and PowerShell has experience with DSC so we thought that could be the sponsor we needed to combine efforts [please correct me].

4. Who is asking for it?

Which team currently needs it and is potentially sponsoring/requesting? WinGet/Internal to PS team?

5. What's the work item priority/agenda/ETA?

Executing against the current plan and hoping to have something to show publicly by Build, in May.

6. The runtime(s)

As the need for this tool is shared through different ecosystems (WinGet for machines, PowerShell, Python, binaries), the CLI tool should be runtime agnostic (standalone), and only call specific runtime implementations when asked to. Those runtimes are plug-ins sharing the same interface, enabling support for resources written in their ecosystem/language. We can imagine having a runtime for Python modules, PowerShell DSC Resources, binary tools like CLI commands, Puppet modules, bicep module and so on. The current plan is limited to make WinGet and PowerShell DSC resources work from the same CLI tool.

7. The Resources: Contract for Config Items

A resource is a contract representing:

How to uniquely address a configuration item for a given system.
The different properties defining the state of a configuration item.
The properties required to set a configuration item (i.e. write only such as Force: true).
What to execute to apply/validate/query (actions or methods of the resource).

To allow for idempotent enactment, the resource must define the Apply/Validate/Query actions. Instances of a resource (whether desired instances or current instances), can be uniquely addressed for a given system (target), while having different configuration item values. Said differently, only one current resource instance exists for a given address (key) on a given system, and we can compare it with a desired resource instance with the same key.

8. Runtime Abstraction

The tool should be designed to work with any type of resource regardless of their runtime. For this, we need to create a common interface, that can be implemented in each runtime that needs to be supported.

This means it has a plug-in model to support different resource runtime, where plug-ins can be registered with the tool. The focus would start with a CLI resource runtime plug-in, a PowerShell DSC Resource runtime plug-in… [please complete the initial plans].

Each runtime should be able to evolve at their own pace, and released independently (but default runtimes packaged with the tool).

9. De/Serialisation

Being language agnostic means only typeless/generic structured data can be transmitted between runtime and the tool, using a common format accessible to all: JSON. Live objects cannot be passed accross, and for this reason the runtime implementation will have more value when integrated in other tools targeted to this language. As an example, a DSC Resource may offer more (extra method, casting to another type...) when invoked through PowerShell than through this tool.

SteveL-MSFT commented 1 year ago

I refer to DSC as the entire platform and specifically PSDSC as the PowerShell module. I can see how that can be confusing, but I try to specifically refer to PSDSC as PSDesiredStateConfiguration module.

The config command referenced is the working name. The final name to be determined. If it conflicts with existing tools, then we MUST change it.

WinGet is just one of the partners we're working with and although the example configuration YAML is heavily tuned to their scenario, it was primarily crafted to be used for conversation to discuss what a YAML based configuration doc may look like that suits their needs as well as general needs.

I 100% agree what's missing in this repo that was primarily covered by conversation is higher level docs, so maybe that'll be the next PR.