Hi Glenn As far as i can tell it sounds good.
Beside that puppet module names can't contain dashes. ;-) - Thomas Am Freitag, 17. Februar 2017 22:42:30 UTC+1 schrieb [email protected]: > > 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 > > - > > Gathering PowerShell DSC resources for conversion (github, Microsoft > DSC, PS Gallery) > - > > Conversion of DSC Resources into module content (lib/type, > lib/provider) > - > > PowerShell Manager codebase. The powershell code that is used by the > DSC providers to acutally do the work. > > puppetlabs/dsc > > - > > Type and Provider Puppet code > - > > DSC Resource files > - > > Depends on the dsc-core module > > > 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 module > - > > By 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. > -- You received this message because you are subscribed to the Google Groups "Puppet Developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-dev/bd9e1f89-18c8-41c3-84c9-9e9dc262059a%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
