make dependsOn robust to flapping readiness state, ratchet on first reconciliation (!8329) · Merge requests · Sylva-projects / sylva-core

Meant to address #4265 (closed)

This MR changes the way we express dependencies between Kustomizations so that **once a Kustomization considers that it's dependencies are ready, then those dependencies won't later be not considered ready anymore, even if their readiness conditions flaps between Ready=true, Ready=unknown (due to healtchecks) or Ready=false (due to possible temporary issues on some of the resources of the Kustomization). Of course if a Kustomization actually changes, then this "keeps being considered ready by dependents" property should not persist.

This is meant to have a "ratchet effect", ensuring that the progress down the dependency tree is monotonic and does not "go back" due to transient conditions.

How this is done:

(context: Kustomization A has a dependsOn Kustomization B)

the dependsOn will be produced at:

dependsOn:
- name: B
  readyExpr: dep.metadata.generation == dep.status.observedGeneration  # (slightly simplified)

this is equivalent to saying that A considers that its dependency B is ready, if B reconciled once on its current generation
- keeping in mind that Flux updates the status.observedGeneration when a resources becomes Ready=true, and not before, and does not revert that during any healthcheck

Note that the dependsOn set on sylva-units-status Kustomization is not changed, so that the point at which we consider that everything is ready is still subject to having all Kustomization be observed with a Ready=True status.

Implication

An implication of this change is that now some units will possibly reconcile while some of their dependencies aren't Ready=true. When this will happen during periodic healthChecks this is absolutely benign. If this happens while a real defect happens on one of those dependency unit, temporary or lasting, this may have side-effects (trying to update unit X relying on service Y while service Y isn't reactive, may lead to having fail to reconcile, or take more time to reconcile); given that services are generally redundant, and that failures are bugs in themselves, this does not seem particularly likely.

CI configuration

Below you can choose test deployment variants to run in this MR's CI.

Click to open to CI configuration

Legend:

Icon	Meaning	Available values
☁️	Infra Provider	`capd`, `capo`, `capm3`
🚀	Bootstrap Provider	`kubeadm` (alias `kadm`), `rke2`, `okd`, `ck8s`
🐧	Node OS	`ubuntu`, `suse`, `na`, `leapmicro`
🛠️	Deployment Options	Deployment option list and description
🎬	Pipeline Scenarios	Available scenario list and description
🟢	Enabled units	Any available units name, by default apply to management and workload cluster. Can be prefixed by `mgmt:` or `wkld:` to be applied only to a specific cluster type
🔴	Disabled units	Any available units name, by default apply to management and workload cluster. Can be prefixed by `mgmt:` or `wkld:` to be applied only to a specific cluster type
🏗️	Target platform	Can be used to select specific deployment environment Available platform list and description
⚡	Pipeline control	`autorun`, `manual` or `blocking`. Can be used to override global config and start a deployment pipeline the required way

Global config for deployment pipelines

autorun pipelines
allow failure on pipelines
record sylvactl events

Notes:

Enabling autorun will make deployment pipelines to be run automatically without human interaction
Disabling allow failure will make deployment pipelines mandatory for pipeline success.
if both autorun and allow failure are disabled, deployment pipelines will need manual triggering but will be blocking the pipeline

Be aware: after configuration change, pipeline is not triggered automatically. Please run it manually (by clicking the run pipeline button in Pipelines tab) or push new code.

Edited Jun 23, 2026 by Thomas Morin

make dependsOn robust to flapping readiness state, ratchet on first reconciliation

Implication

CI configuration

Global config for deployment pipelines

Merge request reports