Declaring Dependencies

2 min read

In your Katalog, you declare dependencies with dependsOn. Three formats are supported — use whichever fits your style.


Format 1 — Simple list

The most common format. Each entry is a CRD name. The condition defaults to started.

crds:
  database:
    crdFile: database-crd.yaml

  application:
    crdFile: application-crd.yaml
    dependsOn:
      - database      # condition: started (default)

Format 2 — Key-value map

When you need different conditions per dependency:

crds:
  application:
    dependsOn:
      database: started
      cache: ready

Format 3 — Full map

The most explicit form. Useful when tooling or schema validation requires structured objects:

crds:
  application:
    dependsOn:
      database:
        condition: started
      cache:
        condition: ready

All three formats are interchangeable. Mix them freely across different CRD entries in the same Katalog.


Condition semantics

started

The dependency’s informer has performed its initial list and the worker pool is running. The dependency is not necessarily processing CRs successfully — only that it has started. This is the minimum signal and the default when no condition is specified.

Use started when the downstream CRD only needs the upstream CRD to exist and be registered.

ready

The dependency has passed started and additionally reports ready: true on its health endpoint. This means at least one reconcile cycle has succeeded.

Use ready when the downstream CRD creates resources that depend on the upstream having successfully reconciled at least one CR.

healthy

The dependency has passed ready and has no active degradation — zero consecutive reconcile failures, queue depth below the degrade threshold, no error rate spike.

Use healthy for the strictest ordering guarantee, typically in production environments where partial readiness is unacceptable.

ConditionMeaning
startedInformer synced, workers launched
readyAt least one successful reconcile
healthyNo consecutive failures, no degradation