DSCResourceManager (aka DSC Resource Resource) about dsc HOT 6 OPEN

@michaeltlombardi that is an interesting point.
I guess the answer depends on whether we want this resource to be part of dscv3 main 'package'.

1. If yes (i.e. we want this resource/resource manager to be the primary deployment mechanism for dscv3 resources) then extensibility in this resource is probably needed.
2. Otherwise, this is just another dsc resource, so if a user wants to support another deployment mechanism, they can simply implement their own resource (aka. resource manager) using a well known API for resources.

At this moment I'm leaning toward #2 just to avoid overengineering.

from dsc.

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.

from dsc.

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.

from dsc.

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.

from dsc.

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.

from dsc.

I'm just working through thoughts on this, so the following may or may not be useful.

1. We create a generic RequiredResources group resource where you can specify an arbitrary list of scalar and group resources that define the DSC Resources used in the configuration, optionally with a version pin.

2. DSC uses the flattened list of those entries to find/install/validate the rest of a configuration before continuing to the get/set/test operations.

   This turns validation potentially into a two-step process. First, is the current configuration blob valid as far as DSC can tell before retrieving the required resources? If not, error now. Second, after the resources are installed/available, are the resources valid against the now-available schemas? If not, error now.

3. The problem with this model is what to do if I need to retrieve a resource-installing-resource - the installer method might need to cycle until all required resources are resolved/installed or it fails.

4. Eventually, the editor extension could handle automatically adding required resources for you when you define an entry in the resources key, or when you run an editor command like Resolve Resource requirements in the current Configuration or whatever. That can help solve some of the DevX pain for having to maintain a list of DSC Resource pins in your configuration.

5. With variables and a composable model, you could theoretically keep your requirements list separate from the main configuration for convenience, but still get validation/IntelliSense while editing and using the configuration.

6. I think any group resources or individual resources that can install resources should maybe be required to advertise that they can be used for this purpose in their tags or another field of their manifest. That would help with discoverability.

7. I'm also wondering if DSC Resources should advertise in their manifest (assuming manifests are published online in addition to being included in a download for a binary) how they can be installed. Again, this can help with discoverability but also with auto-handling.

   I'm thinking about a resource manifest like:

   {
       "$schema": "https://aka.ms/dsc/schemas/resource_manifest",
       "manifestVersion": "1.0",
       "type": "TSToy/gotstoy",
       "version": "0.1.0",
       "install": {
           "type": "DSC/Intall.GitHubRelease",
           "properties": {
               "repo":  "TSToy/gotstoy"
               "version": "0.1.0"
           }
       },
   }

   Then, if the DSC/Install.GitHubRelease DSC Resource isn't already known, DSC can check that published manifest to find how to install it, and so on.

8. One reasonable alternative I see to a model like this is for there to be a repository model for DSC where you publish DSC Resources to it and the dsc command checks the repository for installation. That kinda shifts the problem or at least adds another layer where you need to specify which repository you're using for a configuration - and that repository needs to be reachable. This is made simpler by higher-order tools like Machine Configuration, which could parse the config against a repository and handle sending the resources to the target machine without the target ever knowing or thinking about where the resources come from.

from dsc.