No migration needed for flux-operator

[kingdonb]

I don't think we need to migrate flux-operator installations that have been installed from main branch, it would make sense to build a migration if this version was ever in a release (and FWIW I agree with using Helm to install it, because it allows us to remove nasty hacks like kubectl apply || kubectl apply)

I'm testing this change to see if it resolves https://github.com/aenix-io/cozystack/pull/188#discussion_r1653675391

[kingdonb]

I see what's happening now - you're trying to separate the Flux Operator and the Flux instance installation. I don't think that will work. It's the FluxInstance that manages the lifecycle of the CRD, installs the Flux Helm CRDs, not the flux-operator installation. That's why there is just one FluxInstance per cluster allowed, because when the FluxInstance reconciler upgrades the instance from one version to another, it has to handle upgrading the CRD.

The flux instance needs to be installed before this check will pass, but it has been moved outside of the operator.

# Install fluxcd-operator
if ! flux_operator_is_ok; then
  make -C packages/system/fluxcd-operator apply-locally
fi

# Wait for CRDs
if ! flux_crds_ok; then
  echo "Flux CRDs are not ready" >&2
  exit 1
fi

# Install platform chart
make -C packages/core/platform apply

That's a rational step to take if you were thinking about having more than one FluxInstance per cluster, but it is not supported currently by the flux-operator.

The way it was set up previously with a flux-instance chart that depends on flux-operator, bundled both together. If they were moved back together, I think it would work. We'll have to ask if multiple FluxInstances per cluster are on the roadmap (but I don't see how it would work)

[kvaps]

Thanks for your notesm, I reworked it in https://github.com/aenix-io/cozystack/pull/188

[kingdonb]

Thanks I think you got it 👍