Allowing renaming release when using `helm 2to3 convert`
zx8 opened this issue · 4 comments
Since Helm 2 doesn't provide a way to rename releases (without deleting/re-creating the release), we'd like to use the opportunity to tidy up and standardise some of our release names when we migrate to Helm 3.
It would be extremely helpful if helm 2to3 convert allowed us to specify an optional new name when converting.
Thanks for requesting this functionality @zx8 .
However, I am not sure that this something we should do. My reasoning for this follows.
Some background to start:
- Most charts are designed to use the release name as part of Kubernetes resource creation. This is to enable deployment using the same chart but with different release names.
- During migration, only release metadata is mapped and created for v3. The underlying Kubernetes resources remain untouched.
- A chart can potentially contain an item in it which is named the same as a release name but is not actually aligned to the release name. It is just a coincidence they are named the same.
If this is to be implemented, it would require doing the following:
- Change the release name.
- Search/replace the release name in the release manifests (rendered charts). This would also change an item that happens to be named the same as the the release name.
The potential outcome to the release would be that Helm would no longer be able to manage the release. In other words it would not be able to upgrade, rollback or delete the release properly. There is no longer a connection between the release manifests and the Kubernetes resources in the cluster.
@hickeyma Thanks for the thoughtful response.
I understand this functionality isn't suitable for everyone, but – if I'm following you correctly – for us, I think the caveats you mentioned are all acceptable and will still allow us to clean up and standardise our (static) release names, which have become slightly unstandardised over time.
Reason being, our charts are all maintained internally and use common templates which do not rely on the release name for mapping pods to deployment/releases (i.e. we don't use any official helm/charts chart), so the fact that the release name will change should not have a significant impact on the underlying Kubernetes resources which they manage, because the release name is not included as one of the selector/labels in the manifests.
the fact that the release name will change should not have a significant impact on the underlying Kubernetes resources which they manage, because the release name is not included as one of the selector/labels in the manifests.
If release name is not part of the deployed Kuberntes resources then you could if you want edit the v3 secret object(s) which are the metadata for each release version(s) changing the release name. This is something we would NOT recommend and would be entirely at your own risk.