Reconciliation race: wait timing out due to dependency on shared common-variables configmap

[cpressland]

We're currently using Flux with OCI Artifacts to ship our apps. An example "app" structure looks like this:

$ tree
.
├── backup
│   ├── deployment.yaml
│   └── kustomization.yaml
├── client
│   ├── deployment.yaml
│   └── kustomization.yaml
├── kustomization.yaml
└── namespace.yaml

The root kustomization.yaml:

apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization
resources:
  - namespace.yaml
  - ./backup
  - ./client
namespace: example

All apps expect a common-variables ConfigMap to exist in the namespace. We define it once in a Git-based Kustomization and reuse it across all namespaces. Our GitOps setup looks like this:

apiVersion: source.toolkit.fluxcd.io/v1beta2
kind: OCIRepository
metadata:
  name: example
  namespace: flux-system
spec:
  interval: 10m
  url: oci://example.azurecr.io/example-manifests
  provider: azure
  ref:
    tag: 1.2.65
---
apiVersion: kustomize.toolkit.fluxcd.io/v1
kind: Kustomization
metadata:
  name: example
  namespace: flux-system
spec:
  interval: 60m0s
  retryInterval: 5m
  prune: true
  force: true
  wait: true
  timeout: 10m0s
  sourceRef:
    kind: OCIRepository
    name: example
---
apiVersion: kustomize.toolkit.fluxcd.io/v1
kind: Kustomization
metadata:
  name: example-common-variables
  namespace: flux-system
spec:
  targetNamespace: example
  interval: 60m0s
  retryInterval: 1m
  path: ./bases/common-variables/cluster_name
  prune: true
  timeout: 10m0s
  sourceRef:
    kind: GitRepository
    name: flux-apps

Problem

There's a dependency cycle:

• example-common-variables depends on the example namespace.
• example depends on the common-variables ConfigMap.

Flux eventually reconciles correctly, but when our CI/CD tool triggers reconciliation using flux reconcile kustomization for the first time, we often see this:

Reconciling Kustomization ...
► annotating Kustomization example in flux-system namespace
✔ Kustomization annotated
◎ waiting for Kustomization reconciliation
✗ context deadline exceeded

We suspect this is due to the wait: true setting on the example Kustomization. We require this flag to ensure CI/CD only proceeds after a successful rollout.

Questions

• Is there a way to express this dependency properly to avoid timing issues with wait?
• Can dependsOn be used here? I expect not due to the wait flag.
• Are there patterns to ensure the shared ConfigMap is reconciled before the app without removing wait?

[matheuscscp]

Like in every cyclic dependency problem, you extract the common part out of the cycle and make the other two things depend on it. Then you're free to make one of the two things depend on the other.

But Flux is your friend and it first applies Namespaces, before anything else. In this case you can just move the Namespace to the Kustomization that applies the ConfigMap, and make the other Kustomizations depend on it.

[matheuscscp]

And yes, dependsOn is exactly what you are looking for.