helm: helm cant upgrade already created resources

For the benefit of the group, I just figured I would mention that in order to resolve this ourselves we have started maintaining our own version of helm that we use to transition our users. It has so far been working well, and we’ve used it to successfully “adopt” existing resources into a Helm release manifest during an upgrade procedure. For anyone curious, you can see the changes that we have added here: https://github.com/helm/helm/compare/master...aauren:feat/add-adopt

Basically the change adds a new command-line parameter --adopt to install (whether called directly or with update --install). When called, it takes any existing resources that are found in the cluster, and uses their existing definition as the basis of the patch (instead of an existing helm release manifest) by which to upgrade the resources.

During this process a helm release manifest will be created as part of the upgrade. And after the initial “adoption” all subsequent upgrades can be use vanilla helm as there will be a release manifest available for the resources.

Hopefully this will benefit someone else in addition to us as upstream does not seem interested in this functionality, but yet it seems to be needed by many.

@technosophos @bacongobbler (adding you as well since you were active in other threads on the same subject) We’re in the same boat as some of the other posters in this thread. Because we could not run tiller securely we were using helm template in conjunction with kubectl apply to process our helm deployments. We now have a cluster with many Kubernetes services running in them that were deployed in this manner which do not have release manifests.

Now that Helm 3 is available and it does what we would expect security wise, we are very eager to adopt Helm 3 with the same charts we used before. However, we cannot do that because Helm won’t overwrite objects that it doesn’t have a release manifest for.

I can understand the puristic approach that the Helm project has taken towards this, and I also understand that my use-case likely isn’t all that prevalent. However, as it stands now, I currently see no way to move to Helm 3 adoption without causing significant service disruptions and I can currently find at least 4 open issues right now (#7103, #6561, #5482) including this one, many of them with multiple users, asking about this functionality for one reason or another.

Is there any work around that the Helm team could suggest for addressing this that doesn’t either result in service duplication or deletion? Given that we are blocked I would be willing to donate development time towards implementing a solution if there was a chance that it could be accepted by the project.

We made a defensive decision: If something other than Helm creates a resource, Helm will not alter it. A name collision is treated as an error condition. In our view, it would be an error for Helm to assume that it can “adopt” an existing resource and treat it as part of a release.

Thanks for your efforts @aauren! I’ve built a helm binary with your patch and will give it a try.

#7649 addresses this issue, which will be available in helm 3.2.0. If someone wants to tackle #2730 to make the process easier to adopt resources, feel free.

Closing as resolved. Let us know if there’s something missing.

My slightly different use-case for this is that I want helm to be able to override the coredns configmap resource in a local cluster for being able to resolve domains the way I need it.

Solving the “overtaking” of existing resources would be really awesome. Even better would be to somehow backup the resource that was overtaken and restore upon helm uninstall

@technosophos and how about --replace --force doing the right thing?

There’s a way to override existing hooks:

annotations:
    "helm.sh/hook-delete-policy": before-hook-creation

This annotation specifies Tiller should delete the previous hook before the new hook is launched.

Will that work?