Consistent `spec.dependsOn` and `spec.healthChecks` across release types

[marshall007]

Describe the bug

This was originally reported in fluxcd/kustomize-controller#242 with the explanation from @stefanprodan being:

Is it a better solution if we can remove the type restriction ?

This implies a hard coupling between the two APIs (Kustomization and HelmRelease), I am not in favour of this.

You can add HelmReleases to the Kustomization heath checks, this way dependsOn can be used to create a dependency graph between HelmReleases and other Kubernetes objects.

Originally posted by @stefanprodan in fluxcd/kustomize-controller#242 (comment)

I don't understand this explanation. Expanding spec.dependsOn to be of type meta.NamespacedObjectKindReference (instead of just meta.NamespacedObjectReference) does not imply tight coupling between the controllers, it would just expand the checks to any Kubernetes resource.

Steps to reproduce

A workaround is documented here (same as example copied below): https://fluxcd.io/flux/components/kustomize/kustomization/#kustomization-dependencies

---
apiVersion: kustomize.toolkit.fluxcd.io/v1beta2
kind: Kustomization
metadata:
  name: cert-manager
  namespace: flux-system
spec:
  interval: 5m
  path: "./cert-manager/controller"
  prune: true
  sourceRef:
    kind: GitRepository
    name: flux-system
  healthChecks:
    - apiVersion: apps/v1
      kind: Deployment
      name: cert-manager
      namespace: cert-manager
---
apiVersion: kustomize.toolkit.fluxcd.io/v1beta2
kind: Kustomization
metadata:
  name: certs
  namespace: flux-system
spec:
  dependsOn:
    - name: cert-manager
  interval: 5m
  path: "./cert-manager/certs"
  prune: true
  sourceRef:
    kind: GitRepository
    name: flux-system

This workaround is not flexible enough, particularly in certain multi-tenant setups, because it requires that owners of the resource include the appropriate healthChecks and that both teams specifically use Kustomization CRD. For example, imagine that the latter certs resource is managed by a developer team while cert-manager is managed by the platform operators (using Helm):

# managed by platform-team
apiVersion: helm.toolkit.fluxcd.io/v2beta1
kind: HelmRelease
metadata:
  name: cert-manager
  namespace: cert-manager
spec:
  interval: 5m
  chart:
    spec:
      chart: cert-manager
      version: 1.8.0
      sourceRef:
        kind: HelmRepository
        name: cert-manager
        namespace: cert-manager
      interval: 1m
  values:
    installCRDs: true

# managed by dev-team
apiVersion: kustomize.toolkit.fluxcd.io/v1beta2
kind: Kustomization
metadata:
  name: certs
  namespace: dev-team
spec:
  dependsOn:
    - kind: HelmRelease
      name: cert-manager
      namespace: cert-manager
  interval: 5m
  path: "./certs"
  prune: true
  sourceRef:
    kind: GitRepository
    name: dev-team-repo-a

Expected behavior

Consider making dependsOn and healthChecks both accept meta.NamespacedObjectKindReference and recommend them as standard attributes that SHOULD be supported across all release types. The logic and status checks performed behind dependsOn and healthChecks would be identical. The only difference being that dependsOn blocks rollout progress whereas healthChecks just bubbles up the status (as is already the case).

Code of Conduct

• I agree to follow this project's Code of Conduct

[project0]

Was there any work in this direction? I cant believe its a 3 years old problem without any improvement.

[matheuscscp]

Yes, we improved it. In flux-operator: https://fluxcd.control-plane.io/operator/resourceset/#dependency-management