Auto generating DSC Configuration

DSC
1

Hi $_,

We are planning to implement DSC in our product ecosystem for configuring VMs.Our end users are not much aware of PowerShell and DSC, but they are okay with XML.So we planned to create an XML based input(a kind of Configuration data) which will be converted to DSC configuration data on the fly(I feel this is okay). But we have an idea came in for automatically generating the DSC Configuration script using the autogenerated configuration data and the user input XML.

The reason in place for autogenerating configuration is, all the parameters for a DSC resource will not be necessary on each execution, it will vary based on user input XML. for example.

Configuration Test {
    File NewFile {
        DestinationPath = 'c:\'
        Ensure = 'Present'
        Contents = 'test content'
        Type = 'File'
    }

    File NewFileCopy {
        SourcePath = 'D:\test.txt'
        DestinationPath = 'c:\'
        Ensure = 'Present'
        Type = 'File'
    }
}

Here in above Configuration, we are using the File resource two times,But the end user might only opt Copy file not Create file option, If we are auto generating only the required resource will be created. If we are pre filling the configuration(and making use of configuration data via variables) we will have all the resources in all the possible combinations.

Arguments and Discussions on auto generating the Configuration is still going on, I need some advice here on the best way out of two.

2

I’m not sure I understand what you really have in mind, or maybe I just don’t have enough info.

"We are planning to implement DSC"

Great!

"end users are not much aware of PowerShell and DSC"

They don’t have to, great technology should be invisible to end users! But what’s a end-user for you…

"we planned to create an XML based input"

Please, don’t. No, really, don’t…

I understand they’re familiar with XML, but I doubt they’re born with an XML Parser in their brain :slight_smile: What I mean is that the configuration data should be terse and straight to the point, while understandable by computers.
The configuration data is in the end, the Interface between the human, and the Infrastructure Pipeline (see Whitepapers - PowerShell | Microsoft Learn), so I think XML is not suited as a human interface.
This is the main reason I use Yaml (see https://github.com/gaelcolas/DscInfraSample ).

"automatically generating the DSC Configuration script using the autogenerated configuration data"

Most likely (but I don’t have the full picture here), you should not auto-generate Configuration Script, but working with DSC Composite Resources and configuration data (that’s what my Datum project is about).

"If we are pre filling the configuration(and making use of configuration data via variables) we will have all the resources in all the possible combinations."

I see where you’re coming from, but there’s actually a work around, hence my recommendation on using DSC Composite Resource.
You can use what I call ‘Pseudo-Splatting’ to DSC Resources (it’s like PowerShell splatting for commands but using a custom function…).
I wrote a blog post about it here, and you can find the function’s code there, and an example where it’s used here.

I don’t have all the reasons as to why you’re leaning towards ‘auto-generating’ the configurations, but I’d recommend thinking this through as it sounds like you’re creating a Pet-factory instead of raising cattle…
I understand that some exceptions happen that forces you to have overrides on some configurations based on external factors (location/region, environment, and sometimes at the Node level), and I wrote about that here: https://gaelcolas.com/2018/01/29/the-dsc-configuration-data-problem/.

Hope that helps!

3

$Thanks a lot Gael, Get-DscSplattedResource solves 80% confusions, Let me explore Datum .

#CommunityRocks !!!