Are there two Kustomization types? yes. Really?

[arash-bizcover]

How did you guys get along with these extremely confusing terms at the beginning of the project?
https://fluxcd.io/docs/faq/#are-there-two-kustomization-types

[arash-bizcover]

Is the first Kustomization type just for syncing/reconciling on the second Kustomization.yaml file?
If so, why did you name the kind for it "Kustomization" again??

apiVersion: kustomize.toolkit.fluxcd.io/v1beta1
---kind: Kustomization
+++kind: KustomizationFile / Reconciler / SomethingElseForGodsSake

[kingdonb]

There is no conflict in the Kubernetes API, as kustomization.kustomize.config.k8s.io Kustomization isn't even a resource recognized by the Kubernetes API, even when you are using kustomization overlays. In your file kustomization.yaml you can even totally omit these two lines, and it doesn't change anything about the behavior:

apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization

It's IMHO not confusing at all once you've used it for a while. In every Flux Kustomization there is an implicitly generated kustomization.kustomize.config.k8s.io Kustomize CLI Overlay, generated by the Flux Kustomization Custom Resource from kustomize.toolkit.fluxcd.io/v1beta1. You can also add your own overlay if the auto-generated one isn't doing everything you need. There is also kustomizeconfig.yaml which is another un-typed special file to know about, it can be named anything you want as long as you mention it under configurations: block as shown here.

(In fact this is all still very confusing to me, and I've personally been working on Flux for a while here already, full-time.)

Kustomize is the only applier used by Flux Kustomization in Flux v2, this is also unambiguous. If manifests do not apply with Kustomize, you will need to learn something about Kustomize and update them so they can be applied successfully that way.

I appreciate the feedback and this is not something that sounds completely out of left field, we have heard from a lot of people that these terms are confusing, but really I think it's Kustomize itself that is confusing, and unfortunately there is no escaping that for now, it seems Flux has to force you to learn it one way or another. I think reusing the name does accomplish this by unobsequiously pointing this out so you really can't miss the direct, important association between these resources.

In my opinion when this question comes up, I generally wind up filing it under "Kustomize itself is hard to learn." I do appreciate you filing this issue though, because this issue in particular is definitely going to get a highlight and a direct link at my Flux FAQs talk, if I wind up giving it at GitOpsCon or somewhere else.

[kingdonb]

This issue really belongs on fluxcd/flux2 though, the fluxcd/flux repo is for Flux v1 which is in maintenance: #3320

[arash-bizcover]

Thanks for the detailed response, really appreciate it @kingdonb.

Believe me my brother it is indeed confusing for whoever thinking about it, we don't find a subject confusing when we get used to it because we don't think about it anymore. ask @stefanprodan if you don't believe me.

The reason I'm saying it is confusing is that when we are using normal Kustomization(no fluxcd) we expect the Kustomization yaml object to include (resources, generators, transformers, validators)
But when we install fluxcd for the first time and it generates the files(bootstrap), looking at the flux custom resource Kustomize(kustomize.toolkit.fluxcd.io/v1beta1) inside gotk-sync.yaml, it has the exact kind name kind: Kustomization as the normal overlay file kustomization.yaml. But this file has other specs(interval, path, ......) That is what has made it confusing IMHO

Sorry, the only reason I'm having this discussion is that I believe fluxcd(fluxcd2) is a valuable project.

[arash-bizcover]

look what I found:
fluxcd/flux2#321

[urashidmalik]

It is super confusing.