Is your feature request related to a problem? Please describe.
apl-operator has no readinessProbe and no machine-readable "platform converged" signal. helm install --wait returns as soon as the operator Deployment is available — which is long before the helmfile pipeline has actually reconciled the platform. Bootstrap tooling therefore has nothing reliable to gate on: it either proceeds too early (into a not-yet-ready platform) or polls Argo/pod state and guesses. This missing signal is a root cause of the Argo health-check tolerance hacks, inflated retry budgets, and resync-nudger CronJobs adopters build to survive the first-boot window.
Describe the solution you'd like
A real readiness signal that reflects helmfile pipeline state, not just Deployment liveness. Options, roughly in order of usefulness:
- A readinessProbe on apl-operator that only goes Ready once the current helmfile apply has converged.
- A status object/CR (e.g. an
AplStatus/condition) that reports pipeline phase and last successful reconcile, so kubectl wait / GitOps can block on real convergence.
- At minimum, a documented, machine-checkable "platform is Ready" contract.
Describe alternatives you've considered
Downstream we poll Argo app health, override health checks (ESO/OpenBao not-ready → Progressing not Degraded), inflate retry budgets, and run a resync-nudger CronJob — all compensating for the absence of a first-class convergence signal.
Additional context
Related to #3389 (the secrets-stack bootstrap window), but the missing convergence signal is a distinct, more general gap: it affects any bootstrap automation that needs to know when apl-core is actually done, regardless of which components are enabled.
Is your feature request related to a problem? Please describe.
apl-operator has no readinessProbe and no machine-readable "platform converged" signal.
helm install --waitreturns as soon as the operator Deployment is available — which is long before the helmfile pipeline has actually reconciled the platform. Bootstrap tooling therefore has nothing reliable to gate on: it either proceeds too early (into a not-yet-ready platform) or polls Argo/pod state and guesses. This missing signal is a root cause of the Argo health-check tolerance hacks, inflated retry budgets, and resync-nudger CronJobs adopters build to survive the first-boot window.Describe the solution you'd like
A real readiness signal that reflects helmfile pipeline state, not just Deployment liveness. Options, roughly in order of usefulness:
AplStatus/condition) that reports pipeline phase and last successful reconcile, sokubectl wait/ GitOps can block on real convergence.Describe alternatives you've considered
Downstream we poll Argo app health, override health checks (ESO/OpenBao not-ready → Progressing not Degraded), inflate retry budgets, and run a resync-nudger CronJob — all compensating for the absence of a first-class convergence signal.
Additional context
Related to #3389 (the secrets-stack bootstrap window), but the missing convergence signal is a distinct, more general gap: it affects any bootstrap automation that needs to know when apl-core is actually done, regardless of which components are enabled.