Sounds good to me too. The current process to rebuild the DSC module is overly complex for most Windows admins with little to no experience setting up ruby build tools on a Linux server. I also like the ideas of creating a separate build module (core) and support for class based resources. Separating the build tool from the implementation module creates a lot more flexibility for organizations. We don't need a lot of the base Microsoft DSC resources, so being able to pull out the SharePoint DSC resource will make our Linux admins very happy since they won't have hundreds of unneeded dsc resource files being synced to their servers. The community is starting to move more towards class based dsc resources, so the lack of support in the Puppet DSC module will become more and more limiting. I've already had to tell some of my users that they can't write class based because Puppet can't support it.
Thanks, Derek Robinson On Friday, February 17, 2017 at 3:42:30 PM UTC-6, glenn...@puppet.com wrote: > > 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 puppet-dev+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-dev/2bbf684c-175c-4d15-ad8a-3f8aee97f407%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
