Repository navigation
Self-contained configuration and resources package #463
Description
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.
Reacted by Mikey Lombardi (He/Him), gaelcolas and SeanGraySage
Activity
theJasonHelmick commentedon Jun 17, 2024
+1
hansze commentedon Jul 3, 2024
Isn't this want Machine Configuration Packages are already doing - would be great if it was aligned with that.
michaeltlombardi commentedon Jul 11, 2024
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 commentedon Aug 16, 2024
My initial thoughts:
.dscpkg(pronounced "DSC package") and use thezipformat..dscpkgis passed todsc.exethe same as a configuration file:dsc config get foo.dscpkgdscpkgcontains a single file with the extension of.dscpkg.yaml,.dscpkg.yml, or.dscpkg.jsondscpkgmanifest has:$schemapointing to the schema and version of the package manifestmetadataproperty 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)resourcePathwhich takes an array of strings to relative paths within the zip to search for resourcesallowCoreResources(not sure ifCore,Builtin, or something else describes this better) that is a boolean whentruewill include thedsc.exehome to search for resources (this is where thegroup, etc... resources reside). Default isfalseif not specified.configurationFilewhich is a resolved as a relative path within the zip to a YAML or JSON file that is used as the configuraitonDSC_CONFIG_ROOTis wherever this file resides within the zipremovePackageenum accepts:onSuccesswhen the operation is successful, thedscpkgis deletedalwaysthe package is always deleted even if it failedneverthe package is never deleted (this is default)