Chart name must be unique per version#7
Conversation
This changes the `metadata.name` attribute on the Chart.yaml file to be unique per chart version. This is an unfortunate burden of making it possible to install the Chart.yaml into a cluster, and have the name be unique per thing we care about. h/t to @kfox1111 for noticing this.
technosophos
force-pushed
the
docs/proposal-chart-yaml-name
branch
from
57ef07a to
a471142
Compare
| kind: Chart | ||
| metadata: | ||
| name: myChart | ||
| name: myChart-0.1.0 |
There was a problem hiding this comment.
Ick. For three reasons:
- There is a
versionproperty and the version in the name. - How many people would expect the name to include a version? It's going to make people have to think.
- If we are working with the Application CRD, why does the Chart.yaml need to be install-able? What's the use case?
There was a problem hiding this comment.
I agree with Matt that this will be confusing. With the Application CRD and Release/ReleaseVersion CRDs, I also think that the Chart.yaml doesn't need to be installable. IMO Chart.yaml should be used for chart repo metadata (index.yaml) and used to generate Application, Release and ReleaseVersion objects.
There was a problem hiding this comment.
We don't really know if we are going to use the Application CRD. It's still too much in flux.
But if we do, there's probably no compelling reason to turn the Chart.yaml into a resource-like thing anyway.
The problem is that in the present spec, there can only be one such application/version per namespace, which is not at all the desired behavior. And the only way to get around that is to change the metadata.name field.
There was a problem hiding this comment.
We don't really know if we are going to use the Application CRD. It's still too much in flux.
We should figure out the criteria on go/no-go soon. At least for first pass on direction. If we don't go the Application CRD and everyone else does we end up shifting expectations onto chart developers to create this if they want to do things like display their apps in dashboard.
The problem is that in the present spec, there can only be one such application/version per namespace
I'm not sure why a name needs to have a unique name/version. What if, in the same namespace, I deploy multiple wordpress charts at the same version? Uniqueness is gone for a name in a namespace in this model.
What's the underlying use case?
There was a problem hiding this comment.
Unique name is imposed by Kubernetes.
So the bottom line to me is:
- If we are modeling a Chart.yaml as something installable, then we have to design it to be actually installable.
- Otherwise, can we just drop the "let's pretend this is a Kubernetes resource" crap and stick with our simpler YAML format from Helm 2?
There was a problem hiding this comment.
See #12, which is probably the better course of action.
|
Closed in favor of #12 |
- Fix security section: plugins downloaded, not pre-packaged in charts - Replace Pkl with YamlScript as primary render example (Pkl blocked on Java/Wasm support, but kept in file targeting examples) - Move SDK API from open issues to specification (already designed) - Move Airgap Support from open issues to specification (decided on registries.conf) - Add SourceFiles to built-in objects, link Template to open issue - Clarify implementation plan: ref impl complete, upstream pending - Add rejected idea helm#7: pre-packaging plugins within charts - Update reference link to YamlScript Helm discussion Signed-off-by: Scott Rigby <scott@r6by.com>
4 participants
This changes the
metadata.nameattribute on the Chart.yaml file to beunique per chart version. This is an unfortunate burden of making it
possible to install the Chart.yaml into a cluster, and have the name be
unique per thing we care about.
h/t to @kfox1111 for noticing this.