Repository navigation
Conversation
…ealthy
In the health.lua snippets, the first status check read
obj.status == nil or next(obj.status) == nil and contains(has_no_status, obj.kind)
Lua binds `and` tighter than `or`, so this evaluates as
`obj.status == nil or (...)`: every resource without a status was
reported Healthy, regardless of kind. A managed resource or composed
resource that was just created (and has no status yet) therefore shows
Healthy for a moment, which lets Argo CD move on to the next sync wave
or run PostSync hooks before the resource is ready. The following
branch also dereferenced `obj.status.users` when `obj.status` was nil.
Merge the two branches: a resource without conditions is Healthy only
when its kind is in the no-status list (with a "Resource is in use."
message when `status.users` is set), otherwise it stays Progressing.
This matches the fix in the Argo CD built-in Crossplane health checks
(argoproj/argo-cd#29381).
Also add EnvironmentConfig and ImageConfig, which have no status, to the
crossplane.io no-status list, and note that Argo CD v3.1+ ships built-in
health checks for these API groups which a resource.customizations entry
overrides.
Signed-off-by: Tobias Kässer <tobias.kasser@upbound.io>
✅ Deploy Preview for crossplane ready!
To edit notification comments on pull requests, go to your Netlify project configuration. |
This branch has not been deployed
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
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.

The health checks in the Argo CD guide report every resource without a status as Healthy, whatever its kind.
Lua binds
andtighter thanor, so this evaluates asobj.status == nil or (next(obj.status) == nil and contains(...)).Effect: a managed resource that was just created has no status yet, so it shows Healthy for a moment. Argo CD gates sync waves and PostSync hooks on health. The next wave or hook can therefore start before the resource is actually ready.
Second bug: the following branch reads
obj.status.userswhenobj.statusmay be nil.This PR:
status.usersis set). Anything else stays Progressing. This matches the fix in the Argo CD built-in Crossplane checks (crossplane MRs go to Healthy before the MR has been provisioned argoproj/argo-cd#29381, in Argo CD v3.6).EnvironmentConfigandImageConfigto the*.crossplane.iono-status list. Neither has astatus, so they currently stay Progressing.*.crossplane.ioand*.upbound.io. Aresource.customizationsentry, wildcards included, takes precedence over them.It applies to
master,v2.2,v2.3andv2.4(identical files) andv1.20(same fix, v1 kind list kept), following #1091.Testing
I ran each snippet through
argocd admin settings resource-overrides health(CLI v3.0.6). The wildcard keys were swapped for exactgroup/Kindkeys, because the admin command doesn't resolve wildcards. 21 fixtures:ec2.aws.upbound.ioandec2.aws.m.upbound.ioInstance)kubernetes.crossplane.ioObjectwithout statusReady=True/Ready=False/Synced=FalseProviderConfigwithout status,status: {},status.usersClusterProviderConfigwithstatus.usersValidPipeline=True, XRDEstablished=True, inactive MRDInstalled=False/ healthy, ProviderRevisionRevisionHealthy=TrueThe Vale job reports issues on
content/v1.20/.... These are on lines this PR doesn't touch, and #1091 hit the same failure. The other four files lint clean.