flux bootstrap generates the flux-system Kustomization object with a wrong path

[aristapimenta]

Describe the bug

When running something like this:

flux bootstrap github --owner <my-org> --repository <my-repo> --path ./clusters/cloud-dev

The generated path of the Kustomization object in gotk-sync.yaml is exactly ./clusters/cloud-dev, but it should actually be ./clusters/cloud-dev/flux-system.

Steps to reproduce

1. Install Flux with basic options, like this: flux bootstrap github --owner <my-org> --repository <my-repo> --path ./clusters/cloud-dev
2. Create a raw manifest at ./clusters/cloud-dev/another-namespace/some-manifest.yaml, e.g. a simple ConfigMap
3. Reconcile
4. Observe that the ConfigMap is deployed with the following labels:

  labels:
    kustomize.toolkit.fluxcd.io/name: flux-system
    kustomize.toolkit.fluxcd.io/namespace: flux-system

Expected behavior

It doesn't make much sense to me to have a directory called flux-system under ./clusters/cloud-dev with a matching Kustomization object that synchronizes everything under ./clusters/cloud-dev, and not only under ./clusters/cloud-dev/flux-system.

Screenshots and recordings

No response

OS / Distro

Ubuntu 20.04

Flux version

v0.38.3

Flux check

N/A

Git provider

No response

Container Registry provider

No response

Additional context

No response

Code of Conduct

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

[stefanprodan]

The generated path of the Kustomization object in gotk-sync.yaml is exactly ./clusters/cloud-dev, but it should actually be ./clusters/cloud-dev/flux-system.

If we do this then it would impossible for Flux to deploy and manage infra and apps. Please see the example repo: https://github.com/fluxcd/flux2-kustomize-helm-example.

If you don't like how we designed bootstrap feel free to write your own procedure, but changing how it works would break all Flux users.

[aristapimenta]

The generated path of the Kustomization object in gotk-sync.yaml is exactly ./clusters/cloud-dev, but it should actually be ./clusters/cloud-dev/flux-system.

If we do this then it would impossible for Flux to deploy and manage infra and apps. Please see the example repo: https://github.com/fluxcd/flux2-kustomize-helm-example.

If you don't like how we designed bootstrap feel free to write your own procedure, but changing how it works would break all Flux users.

Maybe I'm just misunderstanding the intended use here. Are there valid use cases to have manifests in directories matching ./clusters/<cluster-name>/<some-dir-not-flux-system>/manifest.yaml managed by the Kustomization object defined in gotk-sync.yaml?

[stefanprodan]

Try out the demo repo then run flux tree kustomization flux-system, you'll see how the root Flux Kustomization applies all the other ones along with Flux itself. If the root one would only apply the flux-system dir, then no one would provision the actual apps and cluster addons.