search

intel / intel-device-plugins-for-kubernetes

Collection of Intel device plugins for Kubernetes
Apache License 2.0
35 stars 203 forks source link

Prepare 0.30.0 release #1731

Closed tkatila closed 2 months ago

tkatila commented 5 months ago

Checklist:

hj-johannes-lee commented 4 months ago

There is an error related to this commit. https://github.com/k8s-operatorhub/community-operators/actions/runs/9137548241/job/25127696012?pr=4366#step:3:5083

And, it seems that the ci/cd tests in the operatorhub has a specific namespace 'testeupgrade', which may mean that we cannot publish the bundle as it is now.

I tested also locally, and it shows the same error messages. In addition, when I test removing the contents of the commit above, it runs successfully.

What do we need to do?

mythi commented 4 months ago

What do we need to do?

Find out what the error is about and plan the fix accordingly. I'm not clear why it fails. Did you check what the test case is about and what we are doing wrong?

tkatila commented 4 months ago

I wonder if it's some upgrade test where the changed labels causes confusion.

edit: nevermind, apparently I can't read.

The fix that is causing this was related to the operator bundle (or multiples of them) so reverting the fix would just re-introduce the issue. Kinda.

hj-johannes-lee commented 4 months ago

Thanks to the help of @tkatila, i figured out that it is not possible to change the labels from the previous version.

We added one more from the previous version, so it is not possible to upgrade from the previous version. I can see some similar case (https://gitlab.com/gitlab-com/gl-infra/production-engineering/-/issues/7331).

I found one source that talks about solving this problem. https://olm.operatorframework.io/docs/troubleshooting/clusterserviceversion/

So, we may need to publish 0.30.0 that does not cause a problem with the addition of new label and then 0.30.1 which would be 'real version' of published operator.

hj-johannes-lee commented 4 months ago

https://github.com/k8s-operatorhub/community-operators/pull/4375 I can see all tests got passed. So, I guess, we have two options.

  1. Change the name of the deployment from inteldeviceplugins-controller-manager to something else permenantly
  2. Change the name of the deployment from inteldeviceplugins-controller-manager to something else temporarily and change back with 0.30.1 version.

The reason why I am suggesting the second option is because I do not know if we need to 'keep' the current name inteldeviceplugins-controller-manager.

hj-johannes-lee commented 4 months ago

@mythi @tkatila Let me know which way you think is better! :)

tkatila commented 4 months ago

I'm trying to think of a way that would not include bumping up the version number and creating a patch release.

If we update the name permanently, what are the downsides for it? Some upgrade somewhere would result in two copies of the operator? Are we sure a 0.29.0->0.30.0->0.30.1 upgrade path would work (changin name back and forth)? What if the user upgrades from 0.29.0 to 0.30.1, wouldn't he/she get the same error?

mythi commented 4 months ago
  1. Change the name of the deployment from inteldeviceplugins-controller-manager to something else permenantly

What happens to the old deployment if you add a new (renamed) one as part of the OLM upgrade?

tkatila commented 4 months ago

I submitted a question to the community operators project: https://github.com/k8s-operatorhub/community-operators/issues/4434

hj-johannes-lee commented 2 months ago

It seems that they are not replying anything. Can we just proceed as official document suggests? (changing the inteldeviceplugins-controller-manager to something else permanently)

tkatila commented 2 months ago

After discussing with @hj-johannes-lee I'd propose a transient deployment name change in the operator bundle:

  1. Release 0.30.0 with a different deployment name (only in operator bundle)
  2. Keep deployment name as-is in the main branch
  3. With 0.31.0 release in the operator bundle, the deployment name would "revert" back to the original one
  4. In the 0.31.0 release notes, we would make a note that upgrade from <=0.29.0 to 0.31.0 is not possible without going to 0.30.0 first.
hj-johannes-lee commented 2 months ago

@mythi https://github.com/k8s-operatorhub/community-operators/pull/4375 It's ready to be merged. If you agree to go forward, let me make it merged.

mythi commented 2 months ago

@mythi k8s-operatorhub/community-operators#4375 It's ready to be merged. If you agree to go forward, let me make it merged.

what is the reason for the step 3.?

hj-johannes-lee commented 2 months ago

Umm, to be honest, I think there would be no problem to change to something else permanently (only when it comes to the operatorhub bundle). But, Tuomas thought there might be some problems.

hj-johannes-lee commented 2 months ago

What about then first letting the pr merged and then decide about step 3,4 later?

mythi commented 2 months ago

What about then first letting the pr merged and then decide about step 3,4 later?

works for me. can you also submit a PR here to get that warning fixed?

mythi commented 2 months ago

What about then first letting the pr merged and then decide about step 3,4 later?

works for me. can you also submit a PR here to get that warning fixed?

nevermind, I just ran into #1785

hj-johannes-lee commented 2 months ago

published. deployname is inteldeviceplugins-controller-manager-0-30-0

We can decide later if we change back to inteldeviceplugins-controller-manager or just create a new and permanent one.

mythi commented 2 months ago

The new name looks odd and forces us to make a change...

hj-johannes-lee commented 2 months ago

@mythi what name do you think is good?

mythi commented 2 months ago

@mythi what name do you think is good?

something that is not attached to a specific version (e.g., 0-30-0)

hj-johannes-lee commented 2 months ago

then from inteldeviceplugins-controller-manager to intel-deviceplugins-controller-manager https://github.com/k8s-operatorhub/community-operators/pull/4743#issuecomment-2250136002

tkatila commented 4 days ago

As discussed, let's keep the deployment name same in the bundle (as it is in 0.30.0), and change the deployment name in the project yamls. This will require manual changes for the 0.31.0 bundle but 0.32.0 onward shouldn't require any manual edits.