-
Notifications
You must be signed in to change notification settings - Fork 36
DSCResourceManager (aka DSC Resource Resource) #47
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
Is this resource meant to be pluggable - can someone contribute a backend to it and if so, is that a setting or does it require munging this resource directly? If not, will they have to author their own from scratch? Thinking about (for example) people who want to use pacman, chocolatey, apk, or nix. |
@michaeltlombardi that is an interesting point.
At this moment I'm leaning toward #2 just to avoid overengineering. |
If we follow the current design of a PowerShellGroup Resource (which enables a PythonGroup resource, for example), then it would make sense to simply have different resources for different artifact repository types. If there becomes viable configuration that is cross-platform compatible (vs windows-only or linux distro-only), then someone can always create a higher level abstract resource that internally uses specific repository type resources. |
What if this worked a little like DSC pull service (Windows or AA) where you only needed to specify which modules/versions are needed, and the client-server relationship would handle resolution? Ideally for PowerShell scenarios, we could use PSResourceGet and the customer's preferred artifact repository (potentially ACR). For languages other than PowerShell, maybe it would be specified in the manifest, if the language natively supports dependency resolution? We would have to look at the requirements for things like pip. This would be a massive advantage for machine configuration, because rather than packaging everything into a .zip file, the config could be in the ARM template and the modules could be pulled as needed from a repository. |
I'm just working through thoughts on this, so the following may or may not be useful.
|
It probably makes sense to extend the manifest to optionally allow more metadata about the resource source, dependencies, etc... As for PSResourceGet, keep in mind that DSC v3 is not dependent on PS, so I would expect PSResourceGet to have it's own DSC resource, like winget would have its own, apt, yum, etc... the question is whether it makes sense to have an abstraction resource over those or alternatively we just define guidelines for package manager resources so there is some level of consistency. |
Summary of the new feature / enhancement
Not sure of the name yet, maybe
DSCResourceManager
?The purpose of this resource is to validate required resources or install resources. Installation needs to be OS specific:
Needs to support validation of:
Proposed technical implementation details (optional)
No response
The text was updated successfully, but these errors were encountered: