-
Notifications
You must be signed in to change notification settings - Fork 103
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
Abort plan with FATAL_ERROR if an unknown custom resource deployed #1648
Conversation
… be deployed. Signed-off-by: Andreas Neumann <[email protected]>
…step Signed-off-by: Andreas Neumann <[email protected]>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think we should postpone landing this until we properly wait for CRDs to appear in discovery because we don't do it right now and this might break the current operator
Do you mean wait for CRDs to appear in Discovery in the health check? Because I think that's the only place where we should wait for a CRD to appear, right? |
@ANeumann82 yes, it's basically #1341 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I missed that this already adds the healthcheck so ✅ thanks :)
Currently KUDO throws a normal error which means retry if a task tries to deploy a custom resource which is unknown to the k8s cluster.
This PR changes this to a FATAL_ERROR. CRDs should be installed correctly in a previous task before the next one is started.
To install CRDs correctly within an operator, CRDs now have a health checks so KUDO can wait until the CRD is correctly installed.
Signed-off-by: Andreas Neumann [email protected]
Fixes #1523, #1341