Better status condition #109
Open
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
…et was not deleted & recreated as needed
…te with not owned secret (and fix previous commit)
- Replace single status condition type with multiple ones to better reflect resource reconciliation states. - During reconciliation, update conditions instead of relying on explicit logs, ensuring status information is surfaced in the resource itself while still producing INFO/ERROR logs. - Add condition reasons to distinguish errors originating from S3, the operator, or Kubernetes.
graindcafe
force-pushed
the
better-status-condition
branch
from
bb08087 to
ff5a0fa
Compare
Contributor
Author
|
@Donatien26 should I cancel this PR ? |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Replace single status condition type with multiple ones to better reflect resource reconciliation states.
The only condition was Reconciled, this has been replaced by :
Something to note: a resource now got more than 1 Condition. The hypothesis that there was only one is no longer true (mainly on test and s3instance controller).
During reconciliation, update conditions instead of relying on explicit logs, ensuring status information is surfaced in the resource itself while still producing INFO/ERROR logs.
On reconcile.go and finalizer.go we got both logging + condition update (not always). The call to condition update will by itself write a log. As many as possible direct calls to logging were removed so that all goes through condition update (that will do the log) and send the information to Kubernetes on the resource for the users to read it.
One consequence is that messages were changed and name of the resource(s) were added to the message to not loose information.
Add condition reasons to distinguish errors originating from S3, the operator, or Kubernetes.
As says before, when the Status Condition Type == Degraded, we can say where the problem occured.