0.29.0 never becomes ready #3419
Labels
kind/bug
Categorizes issue or PR as related to a bug.
Comments
ryanemerson
added a commit
to infinispan/infinispan-operator
that referenced
this issue
Oct 25, 2024
|
FWIW I see the same problem on minikube: |
jmazzitelli
added a commit
to jmazzitelli/kiali
that referenced
this issue
Oct 29, 2024
There is a bug in OLM v0.29.0 that causes OLM not to start. Use v0.28.0 for now until OLM is fixed. See: operator-framework/operator-lifecycle-manager#3419
I also want to say that we (Kiali team) start it a different way, but get the same error. Here's how we deploy OLM: https://github.com/kiali/kiali/blob/v2.0.0/make/Makefile.olm.mk#L249 REPLICATION PROCEDURES TO SEE THE ERROR:Basically, download the install.sh and pipe it to bash. You can replicate the problem easily on minikube:
|
jmazzitelli
added a commit
to kiali/kiali
that referenced
this issue
Oct 29, 2024
There is a bug in OLM v0.29.0 that causes OLM not to start. Use v0.28.0 for now until OLM is fixed. See: operator-framework/operator-lifecycle-manager#3419
|
We face the same on k3d: We used the same procedure to install OLM as @jmazzitelli and faced exactly the same issue. |
|
The issue appears to be that the |
2 tasks
|
Here is the job which generated the release. There is a step called "Generate quickstart release manifests" and I see some mentions of Generate quickstart release manifests logs |
|
OLM_VERSION in the repo root still contains operator-lifecycle-manager/Makefile Line 333 in 06edf28 But it is not clear to me how all the releases after |
|
Ok, I think I understand the issue now. In the release workflow we pass the actual version here: But we no longer read it in the |
|
@m1kola Thanks for diving into this, It seems like #3280 should have been broken into more manageable pieces so it could have been better reviewed. A PR with ~1800 changes can't be reviewed properly IMO. Is the plan to merge in #3426 and re-release |
I'm a big fan of small PRs and this one could've probably been spliced into smaller ones. But to be fair - most of the file changes are in vendor directory. We just missed the fact that
I'm not a big fan of replacing releases and I'm not sure that our tooling supports this. Probably will be better to create a new release and potentially remove the old one. Once #3426 is ready to go in I'll think about it. |
Maybe all that's needed is to remove the assets from |
|
is it only olm.yaml that's affected or are crds.yaml affected too? |
|
So -- what's the final solution? Is 0.29.0 fixed or is another release coming? |
|
We had a discussion in K8s slack in this thread and it was decided that the best course of action is:
|
This was referenced Nov 1, 2024
|
We have a number of issues with release automation tooling which we need to resolve. I fixed some, but we are still not 100% recovered. So far I merged the following: But it looks like our manifests get populated with arch specific image refs based on the CI arch instead of a ref of I also noticed that this issue got automatically closed. Re-opening for now. |
|
We just released v0.30.0. I'm sorry it took so long to address this: we had several issues due to changes in the release automation which needed to be addressed and while fixing these we also discovered some other issues. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Bug Report
What did you do?
We regularly install the olm-operator on KinD using
operator-sdk olm install. This has started failing since 0.29.0 has come out. 0.28.0 installs just fine. We're using the latest version ofoperator-sdk(v1.37.0)Here's a log:
The containers fail to start with
CreateContainerConfigError. Here's the relevant event log:What did you expect to see?
A working installation of olm-operator using
operator-sdk olm installWhat did you see instead? Under which circumstances?
Deployment never becomes ready.
Environment
0.29.0
v1.29.2
KinD cluster
Possible Solution
Looks like
container has runAsNonRoot and image will run as rootfrom the event log is the issue, but there might be more.Additional context
Add any other context about the problem here.
The text was updated successfully, but these errors were encountered: