I haven't had a chance to attempt a reproduction yet, but looking at our code, I think we have a few problems if installNamespace changes on a ClusterExtension that has a successful installation.
We will not find the installed version in the previous install namespace, so our reconciler will treat it like a new install (assuming a helm release in the new install namespace doesn't already exist)
We will not do anything with the helm release in the previous install namespace, which essentially means orphaning it.
I don't know for sure, but there may be issues transferring any shared objects between the old and new release manifests.
Options include:
Make the spec.installNamespace field immutable. This has implications on users that want to relocate a cluster extension. We would likely need spec.deletionPolicy: orphan to make this tolerable to those users.
Stop using helm releases. Use helm template instead? This has implications on support for helm hooks, but perhaps we detect and reject manifests that use hooks. This option would eliminate the problem described in #923 as well.
I haven't had a chance to attempt a reproduction yet, but looking at our code, I think we have a few problems if installNamespace changes on a ClusterExtension that has a successful installation.
Options include:
spec.installNamespacefield immutable. This has implications on users that want to relocate a cluster extension. We would likely needspec.deletionPolicy: orphanto make this tolerable to those users.helm templateinstead? This has implications on support for helm hooks, but perhaps we detect and reject manifests that use hooks. This option would eliminate the problem described in #923 as well.Any other options folks can think of?