Open Xzelsius opened 1 month ago
Hi! The issue you are seeing is not intentional, currently looking into this. In the meantime, just to confirm, is this only occurring when rolling back in the UI? And are there any additional details in your setup that might be helpful for recreating the issue?
I only tested it in one of our Azure Kubernetes Clusters. If I find some time tomorrow I can try it out in another cluster or with another Helm Chart to see if it happens for everything.
Using the Helm CLI does work without issue
@Xzelsius Just a reminder: if you are still running into this issue and would like us to get a fix in, any additional info would be super useful here as I've personally been unable to reproduce this locally
So I tested it again with the v1.30.5 with the Redis Helm Chart
helm install redis --namespace redis --create-namespace oci://registry-1.docker.io/bitnamicharts/redis
redis
helm upgrade redis --namespace redis --create-namespace oci://registry-1.docker.io/bitnamicharts/redis
redis
Apps > Installed
and selected the Redis App
redis
So using a very basic Helm Chart works without any issue!
But at our company, we use an umbrella chart which contains 3 or 4 child Helm Charts. I have yet to try this out on the new AKS cluster (not so easy because the Chart is not public available, and neither are the images)
We have several different namespaces, all with their different Helm releases.
One of our releases in the namespace
grcsaas-default
had an issue, and we had to roll back to a previous version. We did this using Headlamp.But instead of reverting the deployment in namespace
grcsaas-default
it deployed the previous release to thedefault
namespace.Normally, our
default
namespace is empty as we don't deploy anything thereIs this intentional, if so, is there a way (in the UI, we know how to do it in the CLI) to roll back the release in its current namespace instead?