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

describe component/trait version in AppConfig #237

Closed
wonderflow opened this issue Oct 29, 2019 · 3 comments
Closed

describe component/trait version in AppConfig #237

wonderflow opened this issue Oct 29, 2019 · 3 comments

Comments

@wonderflow
Copy link
Member

Now we have versions in annotation both Trait and Component, but we didn't define them in AppConfig, so we don't know which version of Trait/Component was used in AppConfig.

Have version explicitly defined in AppConfig has two benifits:

  1. when we change ComponentSchemic, the runtime could change the version in it's component. After that, when we need to upgrade this Component, we could change the component version in AppConfig.
  2. the same with trait, when we upgrade trait, we could also use the version of trait in AppConfig to let the app operator tell which version he want's to use.
@vturecek
Copy link
Member

vturecek commented Oct 30, 2019

Agreed, we do need a way to allow application operators to specify the version of a component, trait, and scope to use.

The assumption here is that a runtime can have multiple versions of a component schematic, trait definition, and scope definition registered. We can state this explicitly in the spec by saying that a fully-qualified unique identifier for a component schematic, trait definition, and scope definition is:

metadata.name + annotations.version

For example, the fully-qualified name for this component schematic:

apiVersion: core.oam.dev/v1alpha1
kind: ComponentSchematic
metadata:
  name: frontend
  annotations:
    version: v1.0.0
    description: >
      Sample component schematic that describes the administrative interface for our Twitter bot.
spec:
  ...

would be frontend.v1.0.0

The runtime would need to track this. It might require some additional munging of the OAM spec files to get it to work in each runtime.

In the Application Config, name and version can be separate fields, or we can combine into one. I would vote for separate fields so that app operators don't need to refer to the OAM spec to know the format of a combined value.

@wonderflow
Copy link
Member Author

Yeah, I totally agree add a version field into Application Configuration

@wonderflow
Copy link
Member Author

We're talking about Component version issues at #336 and #350, We can discuss more there.

And we have decided that trait won't have version.

Closing

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants