Uploaded image for project: 'Infrastructure Automation Content'
  1. Infrastructure Automation Content
  2. IAC-41

DSC Builder Re-Architecture to Use PowerShell to Generate Puppet Types & Providers



    • Type: Epic
    • Status: Closed
    • Priority: Normal
    • Resolution: Done
    • Component/s: None
    • Labels:
    • Epic Name:
      DSC Revamp
    • Epic/Theme:
    • Template:
    • QA Risk Assessment:
      Needs Assessment



      Prior art on this problem space exists in a google doc from before the implementation of dsc_lite.

      The Builder Is Fragile

      We vendor the PowerShell DSC modules by using a workflow which pulls from a (formerly canonical, now deprecated) repository and our builder code is fragile and often will not work with modules in that repository as they have repeatedly changed management of it. This means that releases of the DSC module recently have improved the execution code but left users stuck with out of date DSC resources being called by Puppet.

      The Builder Is Difficult to Use

      The build system as designed is slow, fragile, and cannot be run without ruby or easily on a Windows machine (due to a dependency on charlock_holmes gem). This means that the most likely users of DSC are most likely to encounter rough edges when using the existing build code.

      The Builder Adds Cognitive Load to the Module

      The builder code lives with the output module, further complicating maintenance and troubleshooting for contributors and users.

      The Output Module is Heavy

      The current DSC module contains over a thousand dsc files alone - these are modulesynced to every node in an environment regardless of whether or not they are needed or used - even in cases where the organization is only using one or two resources total from the module.

      Why should we fix this?

      Hundreds of configuration items for Windows nodes have been written as DSC Resources; practitioners responsible for Windows nodes expect to be able to leverage these resources. Enabling the building of Puppet types and providers to leverage these resources with intellisense and validation differentiates our solution from others in the field and, more importantly, substantially improves the user experience for interoperating DSC and Puppet.

      Proposed Solution, Staged

      • IAC-647: Bootstrap - Fork and adopt james' prototype as a script, ensuring it outputs Puppet modules that can invoke all valid DSC resources (which can be invoked using the Invoke-DscResource cmdlet), validate with initial beta testers.
      • IAC-648: Improve Developer Experience - Convert the script into a Powershell module and release on the PowerShell gallery, enabling users to manually retrieve the PowerShell module to generate Puppet modules containing types and providers mapped to DSC resources. Includes unit and acceptance testing for safety as well as documentation. Publish DSC Resource Kit modules to the DSC namespace on the forge.
      • IAC-649: Streamline & Automate Process - Automate updating of the DSC forge namespace based on releases from PS Gallery, ensuring updated content without the team spending time curating and updating it. Allow community members to contribute new Puppetized DSC modules to automatically update in the DSC namespace.

      Reference: https://confluence.puppetlabs.com/display/ECO/Project+Scaffold%3A+DSC+Builder+Revamp


          Issue Links



              michael.lombardi Michael Lombardi
              erick Erick Banks
              0 Vote for this issue
              4 Start watching this issue



                  Zendesk Support