Self-contained configuration and resources package

[SteveL-MSFT]

Summary of the new feature / enhancement

It may be useful to have a zip package format that defines how to have a self-contained configuration and resources making it easier to deploy configuration without installing resources onto each node.

Proposed technical implementation details (optional)

The zip would contain its own manifest defining the root configuration file (as it may include other configs). Resources would be, by default, constrained to those found in the zip and also ones included with DSC (within the DSC home folder). Optionally, DSC_RESOURCE_PATH can be defined within the manifest. Also have a way to catalog sign the package that is cross-platform compatible which would include hashes of the configs and resources.

[theJasonHelmick]

+1

[hansze]

Isn't this want Machine Configuration Packages are already doing - would be great if it was aligned with that.

[michaeltlombardi]

The existing machine configuration implementation is built around processing the MOF files representing PSDSC configurations - if DSCv3 supports resolving a configuration and its resources into an archive, machine configuration would be able to leverage that artifact instead of redesigning their implementation to operate on v3 configuration documents.

This functionality is also very useful for test scenarios.

[SteveL-MSFT]

My initial thoughts:

• We name the package with the extension .dscpkg (pronounced "DSC package") and use the zip format.
• The .dscpkg is passed to dsc.exe the same as a configuration file: dsc config get foo.dscpkg
• The root of the dscpkg contains a single file with the extension of .dscpkg.yaml, .dscpkg.yml, or .dscpkg.json
  • If more than one file with any of these extensions is found in the root, an error is returned
• The contents of the dscpkg manifest has:
  • $schema pointing to the schema and version of the package manifest
  • Optional metadata property which the author can put whatever they want and isn't used by DSC like: description, author, copyright, license, etc... (it probably makes sense to recommend some standard metadata properties if we expect these packages to be shared)
  • Required resourcePath which takes an array of strings to relative paths within the zip to search for resources
    • Any path that resolves outside of the zip is an error
  • Optional allowCoreResources (not sure if Core, Builtin, or something else describes this better) that is a boolean when true will include the dsc.exe home to search for resources (this is where the group, etc... resources reside). Default is false if not specified.
  • Required configurationFile which is a resolved as a relative path within the zip to a YAML or JSON file that is used as the configuraiton
    • DSC_CONFIG_ROOT is wherever this file resides within the zip
    • Any path that resolves outside of the zip is an error
  • Optional removePackage enum accepts:
    • onSuccess when the operation is successful, the dscpkg is deleted
    • always the package is always deleted even if it failed
    • never the package is never deleted (this is default)
• The zip is unpacked into user temp folder and contents deleted after the operation regardless of success or failure