search

PowerShell / DSC

This repo is for the DSC v3 project
MIT License
133 stars 22 forks source link

allow specifying version, signature, hash of resource #383

Open SteveL-MSFT opened 3 months ago

SteveL-MSFT commented 3 months ago

Summary of the new feature / enhancement

To ensure a specific version (range?) is used or identify of the resource as well as supporting use of different versions of the same resource, we should leverage metadata property to allow describing resource requirements like version (range), hash, etc...

Proposed technical implementation details (optional)

Similar to the execution context for metadata, we can just have metadata at the resource level:

resources:
- name: version1
  type: Test/MyResource
  metadata:
    Microsoft.DSC:
      resourceRequirements:
        version: "[1.0.0,2.0.0)" # nuget version range syntax indicating 1.x.x but not including 2.0.0
  properties:
    a: 1
    b: 2

The Microsoft.DSC namespace avoids collisions, but makes it more nested. Adapters would need to opt-in to support this.

SteveL-MSFT commented 3 months ago

For the version, I remember now that ARM has a apiversion property per resource that is required that we didn't adopt since the name didn't make sense for dsc resources. My suggestion would be to break with ARM here (since we've already broken by not having it required) and call it version and make it optional. When not specified, it's the newest one found. Otherwise, we can accept nuget version range syntax.

michaeltlombardi commented 2 months ago

I think adding the optional version property to a resource instance declaration with a default of latest (or the nuget version range equivalent) makes the most sense and will be the most readable. I would rather write/maintain:

resources:
- name: version1
  type: Test/MyResource
  version: "[1.0.0,2.0.0)" # nuget version range syntax indicating 1.x.x but not including 2.0.0
  properties:
    a: 1
    b: 2

Than the prior example, no questions asked.

The other alternative that occurs to me is appending the version range to the fully-qualified type name syntax, but I think the separate property is better.

SteveL-MSFT commented 2 months ago

Agree with allowing latest (which would be default if not specified) to improve readability