Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Possible bug: Do we properly handle mutations of spec.installNamespace? #961

Closed
Tracked by #950
joelanford opened this issue Jun 20, 2024 · 0 comments · Fixed by #966
Closed
Tracked by #950

Possible bug: Do we properly handle mutations of spec.installNamespace? #961

joelanford opened this issue Jun 20, 2024 · 0 comments · Fixed by #966
Labels
kind/bug Categorizes issue or PR as related to a bug. v1.0 Issues related to the initial stable release of OLMv1

Comments

@joelanford
Copy link
Member

joelanford commented Jun 20, 2024

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.

  1. 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)
  2. We will not do anything with the helm release in the previous install namespace, which essentially means orphaning it.
  3. I don't know for sure, but there may be issues transferring any shared objects between the old and new release manifests.

Options include:

  1. 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.
  2. 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 BUG: data too long issue rendering #923 as well.

Any other options folks can think of?

@joelanford joelanford added the v1.0 Issues related to the initial stable release of OLMv1 label Jun 20, 2024
@joelanford joelanford added the kind/bug Categorizes issue or PR as related to a bug. label Jun 21, 2024
@joelanford joelanford moved this to Done in OLM v1 Jul 9, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
kind/bug Categorizes issue or PR as related to a bug. v1.0 Issues related to the initial stable release of OLMv1
Projects
Archived in project
Development

Successfully merging a pull request may close this issue.

1 participant