Repository navigation
move fluxcd and operator back to system - #188
Conversation
a2d4e05 to
f493b09
Compare
Marian Koreniuk (themoriarti)
left a comment
Marian Koreniuk (themoriarti)
left a comment
There was a problem hiding this comment.
Good improvement.
f493b09 to
460ff8b
Compare
| if kubectl get fluxinstances.fluxcd.controlplane.io -n cozy-fluxcd flux; then | ||
| kubectl delete fluxinstances.fluxcd.controlplane.io -n cozy-fluxcd flux --wait=false | ||
| kubectl patch fluxinstances.fluxcd.controlplane.io -n cozy-fluxcd flux -p '{"metadata":{"finalizers":null}}' --type=merge | ||
| fi |
There was a problem hiding this comment.
I'm not sure I understand the purpose of this migration, is it just designed to evict a flux-operator that has been installed as a core package? There hasn't been a release of cozystack which had shipped flux-operator, and it doesn't look like flux is moving namespaces, I don't think that is needed.
On the other hand, it could be beneficial to move Flux to flux-system for compatibility with some UIs that expect Flux to be in flux-system. That would require a migration. It is not required by flux-operator though, Flux can be in any single namespace, it should be the same namespace as the operator was helm install'ed into.
There was a problem hiding this comment.
Installing flux-operator is designed to take over an existing Flux instance however it was deployed, so long as it's one singular instance and the namespace matches that of the FluxInstance.
There was a problem hiding this comment.
If the goal of this migration is to make Flux Operator user-installable inside of a tenant, I think that further discussion is needed before that will work. Note this is mentioned at the top of the guide docs:
The Flux Operator comes with a Kubernetes CRD called FluxInstance. A single custom resource of this kind can exist in a Kubernetes cluster with the name flux that must be created in the same namespace where the operator is deployed.
There was a problem hiding this comment.
I'm testing it now, if it allows the operator of cozystack to perform self-upgrades then I think it's a go. I don't know about this migration though. What will stop it from deleting FluxInstances / where is the FluxInstance to be deleted expected to come from?
This comment was marked as outdated.
This comment was marked as outdated.
Sorry, something went wrong.
There was a problem hiding this comment.
Hey Kingdon Barrett (@kingdonb) I reworkied this fully, could you check again please?
There was a problem hiding this comment.
Oh, you're right I did something wrong here.
Hey, we didn't make any release since flux-operator was merged, let's remove it.
460ff8b to
5940110
Compare
8634608 to
131a07a
Compare
Signed-off-by: Andrei Kvapil <[email protected]>
131a07a to
f65f968
Compare
3 participants
Separate and move fluxcd and fluxcd-operator from
coretosystem.It should not be problem with self-update now, since we correctly set dependsOn option, it ensures ordered update of flux instance right after flux-operator.
As part of #184 and #185
fixes #169