Flux Operator 0.6

[kingdonb]

This PR upgrades to Flux-Operator 0.6 released this morning, also includes:

• FluxCD Updates #170
  which is an aggregate PR, so Update flux plugin for dashboard #171 Refactor Flux 2.3 update #172 etc. I think this PR now basically subsumes FluxCD Updates #170 and can replace it.

I have at least 80% confidence there are no errors in this PR. It also restores the networkPolicy default and the deleted cozy-dashboard network policy, which we will see fixed (restored to install NetworkPolicy resources by default) in the next flux-operator release.

Ref: controlplaneio-fluxcd/flux-operator#52

Little more testing on my end and then I will mark it as review-worthy. (This PR is still a draft)

[kingdonb]

I tested, was able to get kubeapps to boot with the changes you added 👍 I have also now rebased and am in the process of testing again, had some local environment issues to work out with the multi-arch build

(fwiw I just had to clean up some broken builders from buildx, and be sure to create and set a default builder... then it worked)

docker buildx create --name my-builder
docker buildx use my-builder

Will push over this branch with the rebased commits, so we can review it rebased & with conflicts resolved

Before the rebase we are at 6a097bc

[kingdonb]

I would probably merge this change-set instead of the branch that's currently in #170 upd-flux

Still have to give it a quick once-over to be sure I haven't made any rebase errors, I did a pull --rebase=merges 🧐

[kingdonb]

Now I've tested, and kingdonb/cozystack:0.1.22 properly invokes clusters.networkPolicy: true and Flux pods are able to communicate properly, it seems, so long as they are started after the network policies are in place.

I saw the changes you made to patch source controller advertise address and notification controller, that's pretty ingenious, it seems to obviate the importance of the setting for spec.cluster.domain - a default value of cluster.local

spec:
  cluster:
    domain: cluster.local
    networkPolicy: true
    type: kubernetes

These are the implied defaults, and controlplaneio-fluxcd/flux-operator#52 solves that they are not honored now, in 0.6 operator, so we can remove that setting in our instance template values of cluster.networkPolicy after it merges. I don't know if you want to encourage the "fork the installer to override values" pattern, but this works great for me, I've been able to test every change I've made so far.

I don't want to hold things up clamoring that there still isn't a really good way for users to provide their own custom settings to Flux while we are providing some extensions to the defaults, I think a configmap, but I'm not prepared to solve it now. I think it's OK to move forward with sane defaults.

I'm happy with how this is turning out, because Flux won't be the bottleneck installing. It performs much better with the concurrency set to 20 than the default! (4?) I have some mixed feelings about the way that cluster domain is resolved, but it's not a blocker.

I've still some local end-to-end testing left to do on my part, but smoke test it works, from my end looks good right now.

[kingdonb]

End-to-end testing in here is going pretty well (the latest test build right now is kingdonb/cozystack:0.1.24):

• Deploy (do not merge) kingdonb/cozystack#1

I was able to deploy the full stack, and access the dashboard, and upgrade tenant-root, and deploy a virtual cluster. That's as far as I've got time to test today, (and now I am a bit more familiar with the build system

I managed to built my own dashboard+kubeapps API to be sure I test a specific version - by hand, in a personal Docker Hub repo - and test those with the changes in this branch, in a personal build of cozystack installer)

[kingdonb]

I'll re-target this PR to the upd-flux branch so it's easier to see what the full diff is.

Pretty sure that does not help. I have pointed it back at the main branch, which looks OK because it has already been rebased on main.