Check readiness of Flux kinds using kstatus #4311
Merged
Conversation
This file contains 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
darkowlzz
force-pushed
the
kstatus-readiness
branch
from
f0ea7ce to
9cea270
Compare
This was referenced Oct 9, 2023
Merged
darkowlzz
force-pushed
the
kstatus-readiness
branch
5 times, most recently
from
2524b99 to
e13ab33
Compare
darkowlzz
force-pushed
the
kstatus-readiness
branch
3 times, most recently
from
25a8559 to
c75cdc3
Compare
darkowlzz
force-pushed
the
kstatus-readiness
branch
from
c75cdc3 to
db708de
Compare
darkowlzz
force-pushed
the
kstatus-readiness
branch
from
db708de to
96559e4
Compare
darkowlzz
commented
Nov 28, 2023
darkowlzz
force-pushed
the
kstatus-readiness
branch
2 times, most recently
from
cd61094 to
720396c
Compare
This change replaces all the many functions and ways of calculating readiness of objects into one unified way that uses kstatus.Compute() to check if the object is in progress or current. Only the objects that are current are considered to be ready. This takes advantage of the kstatus compatibility of Flux's APIs and also makes sure that they remain kstatus compatible. The new isObjectReady() function is also aware of static/statusless objects and knows how to check their readiness using kstatus. This prepares the CLI for the upcoming static API objects. All the is*Ready() functions for specific objects have been removed. This change doesn't affect any of the existing tests results. Introduce suspend and resume subcommands for alert-provider. Signed-off-by: Sunny <[email protected]>
darkowlzz
force-pushed
the
kstatus-readiness
branch
from
720396c to
05c13fe
Compare
hiddeco
changed the title
hiddeco
changed the title
hiddeco
approved these changes
Dec 8, 2023
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
While trying to answer and verify the concerns of this discussion fluxcd/notification-controller#540 (comment) about static/statusless objects and their compatibility with kstatus, and also to make #4298 CLI readiness check of static objects, easier and better, I found that all the readiness checks in CLI can be simplified by using kstatus itself and we no longer need to question if our API works with kstatus or not. With this change, all the readiness checks in the CLI will be performed using kstatus. If any of the Flux API objects break kstatus compatibility, they won't work with the CLI. Making it easier to answer what's kstatus compatible and not.
This change replaces all the many functions and ways of calculating readiness of objects into one unified way that uses
kstatus.Compute()to check if the object is in progress or current. Only the objects that are current are considered to be ready. This takes advantage of the kstatus compatibility of Flux's APIs and also makes sure that they remain kstatus compatible.The new
isObjectReady()function is also aware of static/statusless objects and knows how to check their readiness using kstatus. This prepares the CLI for the upcoming static API objects.All the
is*Ready()functions for specific objects have been removed.This change doesn't affect any of the existing e2e test results.
Introduce
suspendandresumesubcommands for alert-provider. This was needed to fully implement thereconcilableinterface for alert-provider in order to use the new common readiness check.flux2 GCP e2e test run with these changes https://github.com/fluxcd/flux2/actions/runs/7031238401/job/19132415957.