-
Notifications
You must be signed in to change notification settings - Fork 536
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
Operator do not upgrade with error "no owned roles found" from olm operator #3156
Comments
After some retries the operator Pod is able to start since the Secret for webhook are created (somehow) by the olm operator. Now I am facing another issue that is an extra service account ( Can someone guide me to find out what is the root cause of that? I think the olm operator error about "no owner roles found" have something to do. From the code there seems to be multiple reasons why that error is shown and debugging just make me think this method contains some hints about the actual check that is failing: https://github.com/operator-framework/operator-lifecycle-manager/blob/master/pkg/controller/operators/olm/requirements.go#L260 |
After rebuilding olm with trace level I was able to found that the extra serviceaccount was indeed the cause of the error "no owner roles found". I am not sure why it get removed but seems that previous version of the operator was creating it since not aware that it was the task of olm operator to create it. Shouldn't olm re-create an extra service account if it does not exists? Is this a bug?? |
Here is the log with trace level I was talking about above:
Is there a way to set trace level with some |
@teoincontatto have you had any updates since your last message? I'm trying to upgrade the pixie operator to bundle OLM v0.26.0 and I'm seeing this same problem consistently with our next release candidate build. |
After going back to this I was able to reproduce the issue locally with the same pipeline. I had to set up a Vagrantfile and a script in order to make it work (see attachments Vagrantfile.zip). It turned out the problem was related to the caBundle field in webhooks that was set to a dummy value. I can not really recall why it was like that but something related to an old Kubernetes version restriction (maybe field was required before?!). The OLM operator was randomly setting the dummy value after changing it (maybe a bug?). Removing the value for caBundle field solved the issue but without reproducing it was impossible to tell what was happening (sometimes the problem didn't appear and the test passed). |
Thanks for providing that context. I was able to debug my problem and while the error message matched what was reported here, my issue was self inflicted and is resolved. |
Type of question
Help troubleshooting a configuration issue
Question
What did you do?
I am testing upgrade of StackGres operator by creating a catalog with current and previous version than a subscription with
startingCSV
set to the previous version (1.7.0) andinstallPlanApproval
set tomanual
. Then I set installplan for previous version to approved. After installation of previous version completes I proceed and install the new version (1.8.0-snapshot) by approving the install plan for the new version.What did you expect to see?
The operator to be fully upgraded and running as expected.
What did you see instead? Under which circumstances?
The operator is not fully upgraded, the install plan
Installed
condition itTrue
, the CSVInstallSucceeded
condition isSecceded
but the opeartor Pod is not starting due to the missing secret for webhooks. Also the olm operator has the following messages:Environment
Additional context
The CSVs of the stackgres operator previous and current versions:
Also, installing the current version (1.8.0) alone works without issues
The text was updated successfully, but these errors were encountered: