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

allow specifying version, signature, hash of resource #383

Open
SteveL-MSFT opened this issue Apr 5, 2024 · 3 comments
Open

allow specifying version, signature, hash of resource #383

SteveL-MSFT opened this issue Apr 5, 2024 · 3 comments
Assignees
Labels
Issue-Enhancement The issue is a feature or idea
Milestone

Comments

@SteveL-MSFT
Copy link
Member

SteveL-MSFT commented Apr 5, 2024

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 SteveL-MSFT added the Issue-Enhancement The issue is a feature or idea label Apr 5, 2024
@SteveL-MSFT SteveL-MSFT added this to the 3.0-RC milestone Apr 5, 2024
@SteveL-MSFT
Copy link
Member Author

SteveL-MSFT commented Apr 6, 2024

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.

@SteveL-MSFT SteveL-MSFT self-assigned this Apr 6, 2024
@michaeltlombardi
Copy link
Collaborator

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
Copy link
Member Author

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

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

2 participants