-
Notifications
You must be signed in to change notification settings - Fork 10
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
feat: add kstatus conforment status updates #284
Conversation
Thank you, but this is a draft PR and is far from over. :)
18ffbe0
to
7f078d1
Compare
controllers/register_status_defer.go
Outdated
) error { | ||
// If still reconciling then reconciliation did not succeed, set to ProgressingWithRetry to | ||
// indicate that reconciliation will be retried. | ||
if conditions.IsReconciling(obj) { |
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.
we should also check if it's not reconciling and mark as ready.
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 was thinking about that, but since we explicitly remove the reconciling condition at the end, we might as well mark it as ready by then. So each controller will take care of marking itself ready at the end.
But maybe it would be better in the defer. 🤔 I'll play around with it and see how it flows. :)
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.
Yeah, this would require checking any potential error values. Because it might be not reconciling because it failed.
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.
Also, I like the explicit mark. We moved away from marking it failed in defer because it was way too obscure.
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.
It depends what is your status when you return with an error. In resources_reconciler.go
you have this :
MarkAsStalled(r.EventRecorder, obj, v1alpha1.AuthenticatedContextCreationFailedReason, err.Error())
This means that you will have stalled
and reconciling
both true if you don't check in the defer I believe. Or you shouldmake sure that the MarkAsStalled
function also unset reconciling condition.
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.
conditions.MarkFalse(obj, meta.ReadyCondition, reason, msg)
conditions.MarkStalled(obj, reason, msg)
Yah, the MarkAsStalled marks ready condition to false.
Okay, here is an object going from Stalled to ready once the secret exists:
note: there are three events because I player around with it. :) Then I created the secret:
The logs where just waiting, so no reconciliation was happening until the moment I created the secret. Once I removed the secret, the component version went into Stalled again. 🎉 🎉 |
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.
Just made once suggestion on the Reason question
Description
Please include a summary of the changes and the related issue. Please also include relevant motivation and context. List any dependencies that are required for this change.
What type of PR is this? (check all applicable)
Related Tickets & Documents
Screenshots
Added tests?
Please describe the tests that you ran to verify your changes. Provide instructions so we can reproduce. Please also list any relevant details for your test configuration
Added to documentation?
Checklist: