For Comment - Fundamental changes to the PowerShell DSC Module
glenn...@puppet.com
Introduction
This is a document about some ideas and thoughts I have about changing the DSC module to better meet users and code maintenance needs
The Problems
User Issues
Unable to use a subset of the Microsoft DSC resources
Confusing to rebuild the standard Microsoft DSC resources
Very confusing to incorporate custom (i.e. user made) DSC resources
Requires a non-Windows, old ruby version OS to build resources
Unable to consume PS Gallery DSC resources easily
Maintainers Issues
Very complex code to import Microsoft and custom DSC resources
Everything is mangled together which can make the initial hurdle of understanding how the module works confusing i.e. Getting resources, parsing the MOF, generating puppet types and providers, the PowerShell manager etc.
Have to rely on github tags for Microsoft DSC resources instead of using the PS Gallery which has been very problematic
Proposed Solution
My proposal is to:
1 - Split the PowerShell DSC Module into two; DSC-Core and DSC modules
Module | Responsibility / Content |
puppetlabs/dsc-core |
|
puppetlabs/dsc |
|
The responsibilities will be split between the two new modules.
The dsc-core module will be responsible for converting DSC Resources into Puppet code, and host any shared Puppet code (mainly the PowerShell manager codebase_
The dsc module will instead only have the Puppet code and DSC Resource files for the standard DSC resource set similar to what we have now.
From a customer's perspective, this means they do not need to change any of their manifests. People using Code Manager/R10K may need to modify their puppetfile to include dsc-core.
Also, this means when we change the PowerShell manager code, users will not need to reimport their resources to take advantage of it, instead they just need to download the latest dsc-core module.
2 - Change the DSC Resource import workflow
The DSC Resource import workflow will be changed so that the generated code is output to a location not within the dsc-core module i.e. the import process looks more like a pipeline e.g.
In the first example we download the Microsoft DSC resources, import them via dsc-core and output to the dsc module (lib/….)
In the second example, we can download only the resources we need, import them via dsc-core and output to an aggregated different dsc module.
We would need to add additional logic to the import process to figure out if it’s installing into a blank module (no metadata.json), and could simply invoke ‘puppet module generate ….’ to create a module skeleton prior to adding the generated puppet code.
Admittedly module generate does have some shortcomings, but it is a good start. If it was determined that it was too simple, we could simply generate our own module skeleton.
3 - Move to a PowerShell based puppet code generator/importer
The MOF parser (in dsc-core) will be converted to use PowerShell instead of a ruby gem. This will enable use to use the native MOF parsing capabilities in PowerShell and also take advantage of class based DSC resources which previously we couldn’t
If at all possible this should only use PowerShell Core features, therefore we could still do the dsc-import process on non-Windows platforms under PowerShell Core.
4 - Move to a PowerShell based resource gatherer
Instead of using only using ruby to gather the DSC resources (only via git or file system), the gatherer should either be re-written in PowerShell or, at least, take advantage of PowerShell to query a PowerShell gallery (Public or Private), which is a common repository for DSC resources.
Like the MOF parser, this should be limited to PowerShell Core so it can be used on non-Windows Platforms.
Why does the proposed solution solve the problems?
By splitting the module into two, we can very succinctly define two use cases:
If you want to apply DSC resources, use the dsc module
If you want to create your own DSC module use the dsc-core moduleBy making the import process more of a pipeline, it’s easier to describe to users and should therefore be easier to manage the codebase behind it
By using PowerShell for both the DSC resource gathering and then generation, there is no need for ruby (probably) at all for creating DSC modules, which makes a lot of sense as a user (particularly for Windows users).
“Why add a dependency to know about ruby to use a purely powershell based thing”By splitting the module we can have different release cadences and not require users to recreate their DSC module when we update shared code (e.g. PowerShell manager)
By using PowerShell core technology we can support building DSC resources on non-Windows platforms (To be confirmed how feasible this is!)
We can also easily consume the PS Gallery and loot all of its riches!By using the PS Gallery tags for the standard Microsoft DSC resource releases we avoid the github tagging issues we had previously.
Possible Implementation
The most difficult piece of work will be the PowerShell core implementation of the MOF parser, with the second most difficult piece being ensuring the PowerShell code works cross platform. Most other PowerShell tasks are relatively simple, or there is sufficient prior art to start from.
There is no hard dependency between the module split and the PowerShell core implementation so both pieces of work could be done at the same time.
We could do unsupported beta releases to customers using a different module name e.g. dsc-resources and dsc-core.
Thomas Müller
As far as i can tell it sounds good.
Beside that puppet module names can't contain dashes. ;-)
- Thomas
glenn...@puppet.com
