Skip to content

Operator doesn't start on informer access error even if stopOnInformerError is set to False #1775

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

Closed
gyfora opened this issue Feb 16, 2023 · 3 comments · Fixed by #1779
Closed
Assignees

Comments

@gyfora
Copy link

gyfora commented Feb 16, 2023

Bug Report

With stopOnInformerError set to false and watching 2 namespaces default,ns1, if I remove the rolebinding for ns1 access the operator won't start correctly.

We get the warn logs ( [WARN ] listSyncAndWatch failed for...) but the operator.start() call does not return until we actually send an event to the other namespace (into default in my case). After that the start returns and the operator starts. (and as expected we continue to receive the warn logs for ns1)

What did you expect to see?

I would expect the operator to start even if the other watched but accessible namespaces do not have any resources in them.

What did you see instead? Under which circumstances?

Environment

Kind

@csviri
Copy link
Collaborator

csviri commented Feb 16, 2023

thank you for reporting, will take a look soon!

@csviri
Copy link
Collaborator

csviri commented Feb 22, 2023

@gyfora , I create a related integration test, but was not able to reproduce the issue.

@csviri csviri reopened this Feb 23, 2023
@gyfora
Copy link
Author

gyfora commented Feb 23, 2023

Maybe this is specific to my local env somehow. I see now that it actually starts but sometimes takes a few minutes... strange.

@gyfora gyfora closed this as completed Feb 23, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
2 participants