support cleanup targeting one specific release

[bitsofinfo]

support cleanup targeting one specific release, right now it appears its all or nothing?

[hickeyma]

@bitsofinfo There is capability like this which is currently available with the --delete-v2-releases flag of the convert command.

The idea of the cleanup command is to do a full cleanup of Helm v2. What is the use case where you only want to cleanup some of the releases?

[rimusz]

I think it makes sense to support cleanup for the specific release as well.
One of use cases you have many releases but want gradually one convert them to v3.
And of course you convert one, test it with helm v3, then do the clean up.

[bitsofinfo]

@hickeyma ok, i wasn't aware of that feature, it could sort of work, however my use-case is to

a) convert X of Y total releases, one by one verify
b) clean each release up one by one. (not all or nothing)
c) we have some releases that will still need to be v2 for a while, but others that I can target for v3 sooner.

I just think it would provide overall more flexibility for migrations, and having a targeted release argument on the cleanup command just is more intuitive as users (like myself) just naturally look there first for the option vs bundled w/ convert

[hickeyma]

@bitsofinfo I understand having this capability adds flexibility for the user. I am just a bit reluctant as the plugin was envisaged to be used to do an in-situ migration asap.

The reason I am interested in your use case is that I wanted to understand how you are using the plugin. In the Helm migration doc, there are 2 use cases shown:

• Strangler pattern: Helm 2 and Helm 3 co-exist on the same cluster. The user manages phasing out Helm v2 gradually and does not require v3 to manage any releases deployed by v2. All new releases are by Helm v3.
• In situ: Migrating Helm 2 to Helm 3 (ASAP). Convert to v3 releases and cleanup using the plugin.

Your use case is a hybrid of the two, in that you convert some releases but want to maintain some of the v2 releases as is. This should work but the onus will be on you to manage releases as Helm v2 could conflict with Helm v3 if try to deploy the same chart with same release name (conflict with k8s resources).

[bitsofinfo]

don't know, to me it seems pretty clear and a legitimate use-case. Yeah the onus is on the operator, however if I validate that the releases I successfully converted to v3, tested and accepted are good to go, there should be not need to force me to retain v2 references to them, because I can't cleanup them up in a targeted manner AFTER the convert command and my validation.

In all reality, all of our releases and supporting charts will covert over fine.

But let's say I have releaseA and releaseB.

1. I convert releaseA. I do NOT use the --delete-v2-releases flag as this leaves me in a non-ideal situation if there is something wrong w/ the converted release in v3 releases, I can't fall back to my v2 release reference.
2. This leaves releaseA and releaseB in v2 releases, and only releaseA is also in v3 releases
3. I validate that releaseA still functions fine as I upgrade the chart via helm3 etc and test
4. I target cleanup only releaseA, leaving only releaseB in v2 releases and releaseA exclusively in v3 releases.
5. I proceed to convert releaseB, it converts, but I notice there is an issue I discover after the fact (such as what I mentioned in Error migration : spec.clusterIP: Invalid value: "": field is immutable #125) that only occurs after the release is in v3 and goings through an upgrade later. In this case, I don't want to remove the v2 reference, but I am sort of forced to continue to use v2 to manage releaseB due to a bug in helm3.

I don't know, its not a big deal to me, I just see no harm in being able to target cleanup specific releases from the v2 releases db, vs only being able to do it as part of the convert process itself which leaves the operator no time to validate the conversion and only then after acceptance go and cleanup the targeted v2 release that was just converted. Not a fan of all or nothing.

thats said, its a great tool, thank you, so far working great!

[hickeyma]

don't know, to me it seems pretty clear and a legitimate use-case. Yeah the onus is on the operator, however if I validate that the releases I successfully converted to v3, tested and accepted are good to go, there should be not need to force me to retain v2 references to them, because I can't cleanup them up in a targeted manner AFTER the convert command and my validation.

I agree adding the capability is good and provides flexibility to the user. The issue is labeled as an enhancement to be added.

I am just a little wary about mixing 2 migration types/use-cases. Mixing both migrating and maintaining releases might lead to issues rather than strangling or migrating fully in-situ. As you say that is the responsibility of the operator.

[hickeyma]

@bitsofinfo Pushed PR #132 for this functionality. Can you give it a try and see how it works for you?

[bitsofinfo]

awesome! thanks. Handing off to @boarder981 to test this, they're working w/ me on this