You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Operators become ready before the CRD has been installed #828
This leads to errors as seen in getting_started scripts (described in a slack thread):
Creating Airflow cluster
error: resource mapping not found for name: "airflow" namespace: "" from "airflow.yaml": no matches for kind "AirflowCluster" in version "airflow.stackable.tech/v1alpha1"
ensure CRDs are installed first
The workaround is to add a sleep 20
Why now
Previously, Helm installed the CRDs, and did so before deploying the operators.
Now Helm deploys the operators without CRDs (by default), and the CRDs are created after the operator pod is up. An apply of a CR that happens straight after that but before the maintainer has created the CRD will fail.
Possible solution
Add a startupProbe endpoint which only gives 200 OK when the CRD has been deployed.
Core: make an operator pod stay not-Ready until its CRD is established. The operator already
computes this (signal::crd_established) apparently so my hope is this is not too hard.
Add a health route reflecting crd_established and a startup probe in the shared Deployment template.
Follow-on: remove the CRD-wait workarounds in the getting-started scripts once readiness stuff works.
Done when
On a fresh install, the operator Deployment reports Ready only after its CRD is established, and
a CR applied immediately after readiness succeeds with no sleep or poll.
The getting-started scripts no longer need their CRD workarounds (each operator seems to use a different one...)
Out of scope
Any other probes (liveness, readiness, ...)
Other health checks
Expected Effort
2-3 days for the endpoint, the probe, a test on one operator, assuming the endpoint can reuse the existing webhook server.
If that is not the case stop and let me know.
The getting-started cleanup and the rollout are not part of that effort.
Operator Deployments now have a startup probe attached, which queries the new /ready endpoint to ensure all CRDs necessary for the operator are installed.
Activity
lfrancke commentedon Jul 22, 2026
Scope
computes this (
signal::crd_established) apparently so my hope is this is not too hard.Add a health route reflecting
crd_establishedand a startup probe in the shared Deployment template.Done when
a CR applied immediately after readiness succeeds with no sleep or poll.
Out of scope
Expected Effort
2-3 days for the endpoint, the probe, a test on one operator, assuming the endpoint can reuse the existing webhook server.
If that is not the case stop and let me know.
The getting-started cleanup and the rollout are not part of that effort.
xeniape commentedon Sep 8, 2026
PRs related to this issue
/readyendpoint to WebhookServer operator-rs#1272(copied from #885 (comment)) Overview of awaited signals in operator rollouts because they were missing (added now through the operator rollout PRs)
TrinoCatalogSparkApplicationTemplateListenerClass,PodListenersSecretClass/readyendpoint to operator deployment secret-operator#759/readyendpoint to operator deployment listener-operator#434xeniape commentedon Oct 8, 2026
Release Note
Operator Deployments now have a startup probe attached, which queries the new
/readyendpoint to ensure all CRDs necessary for the operator are installed.