Improve reconciler handlers to prevent early reconcilation #176
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.
Overview
Addresses LP#2074388 by getting to the heart of the issue -- this charm wasn't protecting against early reconciliation. It was too permissive in the handler checks.
Details
The reconciler pattern hinges on completing all its handlers without a reconciler error being raised. The easiest way to stop the reconciler is therefore to raise an error, and let the next hook determine the charm's actions.
This charm was being too permissive about passing over situations the charm was in that it knew it couldn't progress pass - ultimately it lead to a failure to detect a downed api on the kubernetes-control-plane.
These adjustments attempt to tighten the feedback in the reconciler loop, exit early, and prevent early reconciliation.