Eksctl: Handle "flux already installed in cluster" situation

Created on 2 Aug 2019  ·  4Comments  ·  Source: weaveworks/eksctl

If flux is already installed in the cluster eksctl should handle it earlier.

$ EKSCTL_EXPERIMENTAL=true eksctl install flux -f examples/01-simple-cluster.yaml [email protected]:martina-if/flux-test-2.git [email protected]
[ℹ]  Cloning [email protected]:martina-if/flux-test-2.git
Cloning into '/tmp/eksctl-install-flux-clone194001168'...
warning: templates not found /home/martina/.git_template
remote: Enumerating objects: 3, done.
remote: Counting objects: 100% (3/3), done.
remote: Total 3 (delta 0), reused 0 (delta 0), pack-reused 0
Receiving objects: 100% (3/3), done.
[ℹ]  Writing Flux manifests
[ℹ]  Installing Flux into the cluster
[ℹ]  replaced "flux:Deployment.apps/flux"
[ℹ]  replaced "flux:Secret/flux-git-deploy"
[ℹ]  replaced "flux:Deployment.apps/memcached"
[✖]  You may find the local clone of [email protected]:martina-if/flux-test-2.git used by eksctl at /tmp/eksctl-install-flux-clone194001168
[✖]  Service "memcached" is invalid: spec.clusterIP: Invalid value: "": field is immutable
$ eksctl version
[ℹ]  version.Info{BuiltAt:"1564746220", GitCommit:"0.2.0-46-g35bedce0", GitTag:""}
kinbug

Most helpful comment

Copying discussion from elsewhere:

marc: for defaulted fields like Service#spec.clusterIP, I suspect it isn’t as “smart” as the 3-way-kind-of-diff kubectl apply does? Does anyone now if such logic is exposed by the Kubernetes API? Or will we need to replicate it?
fons: This sort of stuff is why I (and flux itself) used kubectl apply
fons: I think that having kubectl as a dependency is not that bad
fons: Plus it will go away once there is server-side apply support

All 4 comments

Copying discussion from elsewhere:

marc: for defaulted fields like Service#spec.clusterIP, I suspect it isn’t as “smart” as the 3-way-kind-of-diff kubectl apply does? Does anyone now if such logic is exposed by the Kubernetes API? Or will we need to replicate it?
fons: This sort of stuff is why I (and flux itself) used kubectl apply
fons: I think that having kubectl as a dependency is not that bad
fons: Plus it will go away once there is server-side apply support

I don't think we should attempt re-configuration. If user wants to reconfigure flux, they should actually edit files in git, that we’ve checked in for them. If they want to re-install it, we should offer clean reinstall where flux namespace gets deleted. I'd recommend fixing this by checking whether namespace exists. Adding --force-reinstall would be a separate feature.

It's not about reconfiguring. I think that the installation should be idempotent. It may happen that the installation fails and the user wants to retry without any changes. We shouldn't fail because Flux was already created in the cluster.

Two possible approaches for now then:

  1. kubectl apply-ing all Flux manifests again without looking/checking much, as kubectl apply is idempotent out-of-the-box there ;
  2. deleting the flux namespace, and applying all Flux manifests again via CreateOrUpdate.

Anything else before I make a call and start implementing this?

Was this page helpful?
0 / 5 - 0 ratings