You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Output of helm version: na
Output of kubectl version: na
Cloud Provider/Platform (AKS, GKE, Minikube etc.): na
Hi, I have come across a number of occasions where I have some large parent helm charts, that contain many dependencies, but for various reasons, have had the need to move a child chart from one of those parent charts to another one, and without actually losing any data.
I had thought it might be possible to 'move' a child service from one helm release to another, without removing its pods/pvcs etc, so that data is not lost and traffic is not impacted. However I cannot find a straight forward way to do this. Would it be a feature request to support 'moving' services from one release to another?
One approach looked at was creating some sort of a script (or upgrade in changes) to annotate an existing releases objects with 'helm.sh/resource-policy: keep', upgrading that object out of the first release, and possibly try to use 'lookup' to bring the child back into the other/second release as part of an upgrade.
However this approach involves a lot of annotations and addition of 'lookup' in possibly many tens of files (to avoid the second helm releases upgrade from giving errors that some objects already exist). This is why I'm looking to see is there some other / more elegant approach to move a service from helm chart 1 / release 1, to helm chart 2 / release 2, without data loss or deletion of the running pods.
Many thanks for any ideas or inputs.
The text was updated successfully, but these errors were encountered:
Output of
helm version
: naOutput of
kubectl version
: naCloud Provider/Platform (AKS, GKE, Minikube etc.): na
Hi, I have come across a number of occasions where I have some large parent helm charts, that contain many dependencies, but for various reasons, have had the need to move a child chart from one of those parent charts to another one, and without actually losing any data.
I had thought it might be possible to 'move' a child service from one helm release to another, without removing its pods/pvcs etc, so that data is not lost and traffic is not impacted. However I cannot find a straight forward way to do this. Would it be a feature request to support 'moving' services from one release to another?
One approach looked at was creating some sort of a script (or upgrade in changes) to annotate an existing releases objects with 'helm.sh/resource-policy: keep', upgrading that object out of the first release, and possibly try to use 'lookup' to bring the child back into the other/second release as part of an upgrade.
However this approach involves a lot of annotations and addition of 'lookup' in possibly many tens of files (to avoid the second helm releases upgrade from giving errors that some objects already exist). This is why I'm looking to see is there some other / more elegant approach to move a service from helm chart 1 / release 1, to helm chart 2 / release 2, without data loss or deletion of the running pods.
Many thanks for any ideas or inputs.
The text was updated successfully, but these errors were encountered: