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
Creating default "automationbroker" CR results in frozen ASB operator stuck on "injecting owner reference" #1138
Comments
|
I need to determine what about the modified CR leads to a successful provision. Unfortunately, pretty inconvenient thing to test since I haven't found a way to retry without resetting the whole cluster. |
|
sounds similar to this one #1105 |
|
Is it possible that the broker operator needs to be rebuilt with the latest ansible operator image? |
|
@djzager definitely possible. To my knowledge, hasn't been rebuilt in a while. P.S. had a conversation with @mhrivnak on this and found out that it's possible to clean up in this scenario by manually editing the |
|
@djzager I rebuilt the ASB operator image using the latest AO base image from water-hole and tried provisioning with the default CR again... still have the same issue with lockup. Note the updated |
|
@djzager updated my original issue comment. As indicated by the issue you linked that Erik originally wrote, adding |
|
Had a discussion/found a potential solution for this issue with @djzager and @jmontleon . After rebuilding ASB operator on the latest ansible-operator image from water-hole based on operator-sdk v0.1.1, using the default CR spec values did work, but lead to very slow completion of each run of the AO reconciliation loop. Noticed in the ASB operator logs that "Broker ready status" was the final action that ran before seeing "exiting successfully": Thought this delayed "Broker ready" message was strange because we specified to not wait for broker readiness so that the reconciliation loop would run quicker: Seeing that the operator was still waiting for broker deploy to complete, we hypothesized that "false" was not parsed as a boolean with value Turns out removing I've verified that removing the quotes around Proposed solution
|
|
Whoops finger slipped, please ignore above activity. Proposal makes sense to me, good find on the source of the issue. I wonder if there are other values failing more silently in similar ways. |
|
Good point, other quoted boolean values provided in the spec are going to be misinterpreted as well (unless we have boolean casts in place for some vars but not others). I went ahead and updated If you do remove the |
|
Issues go stale after 90d of inactivity. Mark the issue as fresh by commenting If this issue is safe to close now please do so with /lifecycle stale |
|
/close |
|
@jmrodri: Closing this issue. In response to this:
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. |
Bug: Creating default "automationbroker" CR results in frozen ASB operator
What happened
automation-brokerCR with default values in automation-broker namespaceCR I created with default params (doesn't work):
ASB Operator Logs:
What you expected to happen
ASB Operator provisions broker successfully in response to
automation-brokerCR being created, even when default params are provided.Workaround
Creating this CR instead will result in a working Automation Broker instance:
How to reproduce it
Set up a v3.11 env in catasb, subscribe the
automation-brokernamespace to the Automation Broker Operator, and create the defaultautomationbrokerCR to see the freeze.The text was updated successfully, but these errors were encountered: