Opportunity for further abstraction away from PowerShell

[KirkMunro]

Cool concept. I had thought about doing for something similar, but I was considering wrapping DSC in another DSL and hadn't looked at YML as a possible definition language.

One suggestion jumps to mind when I look at this: support "low level" DSC entries in YML (where you specify the module name, like you are dong now), but consider abstracting completely away from those as well so that the yml author doesn't even need to know the DSC module name. The thought here is to get configuration creators away from the mess that is DSC module naming (with "c" and "x" prefixes which are just horrible), and instead have something that is more in line with what they are thinking about when they are setting up the configuration. A picture is worth 1000 words, so....

e.g. What if your Firewall_Example.yml file looked like this instead:

• Service: Name: MPSSvc State: Running StartupType: Automatic

• PublicFirewall: State: On

• PrivateFirewall: State: On

• DomainFirewall: State: Off

• PowerShell ExecutionPolicy: Unrestricted

This approach brings a bunch of changes to the table:

1. It slices and dices DSC resource definitions up and instead uses something that should align with the mental model of the person defining the configuration (i.e. the terms used here match what users see in Windows).
2. It breaks away from one section per resource because there should be no need for that (i.e. PowerShell, or any of these for that matter, could have a bunch of settings that come from different DSC resources).
3. It removes PowerShell completely from the equation (other than the PowerShell configuration entry) by abstracting away from modules, allowing for transitioning from "x" resources to non-"x" resources, and allowing resources define more options to an area to be configured to be used in tandem with existing resources.

Behind the scenes it can use whatever resources are required, and it can use concepts I really don't like such as "ensure" to try to keep node definitions generic across any DSC resource, but in my mind the generic nature of DSC is the biggest weakness that DSC has because it requires users to learn the mental model of DSC and how to apply that model to concepts that they already know and understand. This approach does away with all of that and gives us what I had hoped DSC would be: a simple, declarative way to define the state you want for a given system.

Being able to drop the name of the resource on the line where the resource configuration is being defined makes more sense to me than having Name inside as a parameter.

Anyhow, I haven't thought through all paths here and haven't shared all ideas in my head, but I wanted to start a discussion about a partial brain dump of some things I thought were worth considering with this approach.

Aside: With you're yml syntax, how do you handle dependencies where one configuration should not start until another configuration has finished? I didn't see that in your spec file.

[bundyfx]

Thanks for the feedback Kirk.

You make a great point about further abstracting the module logic from the front-end. This is just another thing that the end user should not need to be concerned with.

I will look into changing up the YAML structure to follow a similar layout as you've suggested as I think it's a great path to follow down to improve this concept.

I totally agree with removing the name parameter in favor for being able to just drop it on the line as you said.

In regards to dependencies:

A little bit of context, vamp -apply is executing an Invoke-DSCresource which by default has a -wait type switch embedded so only one resource is being executed at a time. During the extraction of the YAML, the data gets stored into an ordered hashtable as its pulled from the files. Once stored, the values of the hashtable are pulled out from top to bottom and splatted into Invoke-DSCresource.

So in its current context, it's based on the order that the file objects are passed into the YAML read method. Chaining execution order at a file level would be something I would prefer more so than 'depends on' as it can become repetitive

However, more to your point, as long as the config .yml files are passed into the read method in the same order they are specified in the spec file, everything should run in sequence and thus wait for completion before starting the next config in the list.

How I was thinking about it:

-  nodes:
     name:
     - Server02  <-- runs first
     - Server03 <-- once first has completed
     - Server04 <-- runs last

   configs:
     name:
     - WebServer <-- runs first
     - Firewall_Example <-- then this
     - Git <-- then this

A few thoughts that come to my mind that I'm not exactly sure how to deal with at this stage (some partial brain dump):

Variables - Introducing this concept without over complicating functionality.
Small .yml files Small is nice and basic but can make file management tricky if used abundantly. Ruby style erb templating (looping etc) - Maybe something to think about way further down the line.

Credentials are also tricky, I like the idea that Ansible has with an encrypted vault file as this is OS agnostic. More so, it allows multiple encrypted variables to be stored in a single file which can be used across many configs.

My current thoughts: Would this concept be more applicable in Python? As native cross-platform execution would be (in my opinion) a huge plus.

I would love to hear more of your partial brain dump(s)!

Early days for building on this idea. It's great to know that other's like yourself have had similar thoughts about DSC and how we could make steps to simplifying and broadening its popularity among multi-disciplinary developer/ops teams.