Volker Schmitz

but the flux kustomize could handle that? is this the wrong place than :(

Also this leads into several issues, if the kustomize exists inside a custom namespace, but this needs to be created by another kustomize out of flux-system. for example: gotk-sync.yaml ```yaml...

This would split a component into two separate kustomize.toolkit.fluxcd.io/v1beta2 inside of two different namespaces. This isn't that and a strange dependency :(. Also, both kustomize.toolkit.fluxcd.io/v1beta2 belong to the flux-system ks...

just use my example and you will see that flux stop working because the namespace playground does not exists. It's a chicken egg issue, putting a kustomization (flux) inside a...

Lets try an example: ```yaml clusters/dev/flux-system # default flux-system stuff defining the GitRepo to reconcile --- # clusters/dev/example, inside this git repo apiVersion: kustomize.toolkit.fluxcd.io/v1beta2 kind: Kustomization metadata: name: example-nginx spec:...

> that's own by cluster admins. That is exactly what we don't want. :( Giving developers two kustomizations in hand one "only for namespaces" and the other for the service...

Okay thanks got the point. I guess.