-
Notifications
You must be signed in to change notification settings - Fork 203
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
Prepare 0.30.0 release #1731
Comments
There is an error related to this commit. 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. 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? |
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. |
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 found one source that talks about solving this problem. 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. |
k8s-operatorhub/community-operators#4375
The reason why I am suggesting the second option is because I do not know if we need to 'keep' the current name |
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? |
What happens to the old deployment if you add a new (renamed) one as part of the OLM upgrade? |
I submitted a question to the community operators project: k8s-operatorhub/community-operators#4434 |
It seems that they are not replying anything. |
After discussing with @hj-johannes-lee I'd propose a transient deployment name change in the operator bundle:
|
@mythi k8s-operatorhub/community-operators#4375 |
what is the reason for the step 3.? |
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. |
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 |
published. deployname is We can decide later if we change back to |
The new name looks odd and forces us to make a change... |
@mythi what name do you think is good? |
something that is not attached to a specific version (e.g., |
then |
Checklist:
kube-rbac-proxy
is the latest versiondefault_labels.docker
+ make dockerfilespublish.yml
to create docs for v0.30The text was updated successfully, but these errors were encountered: