Learning about FluxOperator and related resources

[bozho]

@stefanprodan, I've been reading FluxOperator and the D2 reference architecture docs, and I have a few questions, if you don't mind...

If I'm understanding ResourceSet, the first main motivation for it is to reduce boilerplate manifest code for deploying components following the same deployment pattern (e.g. create namespace, service account, roles/bindings, deploy controllers, then controller config from a Git/OCI source). This allows us to easily template out deploying infrastructure components (like in the D2 example) or, for example, deploy multiple instances of an application.

Obviously, in the real world, things may not be that simple, e.g. if we need to deploy CRDs (e.g. gateway-api) or operators (e.g. ECK operator for Elasticsearch) that need to be deployed first, or follow a different pattern, we'd deploy these first/separately using another ResourceSet (or several).

The other motivation I've seen is that, even when deploying a single set of resources (like policies.yaml in D2 example), having them grouped in a ResourceSet allows us to make another ResourceSet depend on it, avoiding the need for another "layer" for GitSource/Kustomization to enforce deployment order. Another nice feature here is that a ResourceSet can depend on any k8s resource, not just another ResourceSet (unlike Kustomization and HelmRelease).

Is this correct? Have I missed anything regarding basic ideas about ResourceSet?

I also have a few practical questions regarding the D2 architecture example...

I see that clusters are bootstrapped via a Makefile, which installs flux-operator using helm (the alternative would be TF, or something else), creates the OCI registry secret and then applies the FluxInstance manifest, which references its own parent directory from the OCI registry.

I'm guessing the FluxOperator manifest in flux-system/flux-operator.yaml will be applied to the FluxOperator installed by helm during bootstrap. Does the bootstrap configuration for the operator have to match the one in the manifest, or is it safe to use a "basic" configuration during bootstrap (e.g. just set multitenancy.enabled=true) and have a more "refined" configuration in the manifest, which will get applied when deploying FluxInstance?

Finally, regarding building OCI artefacts using GitHub actions... I see that the D2 example uses controlplaneio-fluxcd/distribution/actions/setup and controlplaneio-fluxcd/distribution/actions/push actions/.

The "setup" action readme says:

This GitHub Action can be used to download the Flux CLI for Enterprise Distribution versions inside GitHub Workflows.

Does this mean we can only use these actions if we have the Enterprise Distribution licence, or are they free to use?

Thank you very much!

[stefanprodan]

Have I missed anything regarding basic ideas about ResourceSet?

You can read here more about the ResourceSet APIs https://fluxcd.control-plane.io/operator/resourcesets/introduction/

One major feature that is not showcased in D2 is the self-service environments capability, basically being able to deploy to preview clusters changes made in Pull Requests.

Does the bootstrap configuration for the operator have to match the one in the manifest, or is it safe to use a "basic" configuration during bootstrap

The initial configuration at bootstrap can contain the minimal settings for running the operator, this is a one time operation, upgrades and changes to config should go via Git/OCI/Cluster so it's safe to ship a different configuration after the initial handshake.

Does this mean we can only use these actions if we have the Enterprise Distribution licence, or are they free to use?

All the code, actions, configs, docs, etc from the public repos in the controlplaneio-fluxcd org are open source (AGPLv3) and free to use in any form you see fit.

[bozho]

Thank you for your reply!