Skip to content
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

DSCResourceManager (aka DSC Resource Resource) #47

Open
SteveL-MSFT opened this issue Mar 30, 2023 · 6 comments
Open

DSCResourceManager (aka DSC Resource Resource) #47

SteveL-MSFT opened this issue Mar 30, 2023 · 6 comments
Labels
Issue-Enhancement The issue is a feature or idea

Comments

@SteveL-MSFT
Copy link
Member

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:

  • all platforms use powershellget v3 for PS based resources
  • Windows use winget
  • Linux use apt/yum/etc...
  • macOS use homebrew

Needs to support validation of:

  • name
  • author
  • version (including range using nuget range syntax)
  • hash
  • signature (potentially GPG type on Linux?)

Proposed technical implementation details (optional)

No response

@SteveL-MSFT SteveL-MSFT added the Issue-Enhancement The issue is a feature or idea label Mar 30, 2023
@michaeltlombardi
Copy link
Collaborator

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.

@anmenaga
Copy link
Collaborator

anmenaga commented Apr 4, 2023

@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.

@SteveL-MSFT SteveL-MSFT changed the title DSC Resource Resource DSCResourceManager (aka DSC Resource Resource) Apr 16, 2023
@SteveL-MSFT
Copy link
Member Author

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.

@mgreenegit
Copy link
Member

mgreenegit commented Jun 21, 2023

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.

@michaeltlombardi
Copy link
Collaborator

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.

@SteveL-MSFT
Copy link
Member Author

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Issue-Enhancement The issue is a feature or idea
Projects
None yet
Development

No branches or pull requests

4 participants