Cluster-api: Running clusterctl init twice results in an error

[wfernandes]

What steps did you take and what happened:

1. kind create cluster
2. In cluster-api, ./cmd/clusterctl/hack/local-overrides.py
3. clusterctl init --core cluster-api:v0.3.0 --bootstrap kubeadm-bootstrap:v0.3.0 --infrastructure aws:v0.5.0
4. Run the command again,
   clusterctl init --core cluster-api:v0.3.0 --bootstrap kubeadm-bootstrap:v0.3.0 --infrastructure aws:v0.5.0 -v 4 --force

We get the following error:

Updating: /v1, Kind=Service, capi-system/capi-webhook-service
Throttling request took 192.94293ms, request: PUT:https://127.0.0.1:59592/api/v1/namespaces/capi-system/services/capi-webhook-service
Error: failed to update provider object /v1, Kind=Service, capi-system/capi-webhook-service: Service "capi-webhook-service" is invalid: spec.clusterIP: Invalid value: "": field is immutable

This error makes sense because according to the docs clusterIP cannot be updated.

What did you expect to happen:
I expected the second update to succeed.

Environment:

• Cluster-api version: 7b2ad211f455008497059918da18085539f74115
• Minikube/KIND version: kind v0.6.1 go1.13.4 darwin/amd64
• Kubernetes version: (use kubectl version):
  > Client Version: version.Info{Major:"1", Minor:"15", GitVersion:"v1.15.3", GitCommit:"2d3c76f9091b6bec110a5e63777c332469e0cba2", GitTreeState:"clean", BuildDate:"2019-08-19T12:36:28Z", GoVersion:"go1.12.9", Compiler:"gc", Platform:"darwin/amd64"}
  Server Version: version.Info{Major:"1", Minor:"16", GitVersion:"v1.16.3", GitCommit:"b3cbbae08ec52a7fc73d334838e18d17e8512749", GitTreeState:"clean", BuildDate:"2019-12-04T07:23:47Z", GoVersion:"go1.12.12", Compiler:"gc", Platform:"linux/amd64"}

/kind bug
/area clusterctl

[fabriziopandini]

@wfernandes
IMO, the cleanest approach to re-install, is to delete* first and then re-install, not to override using init --force(*unfortunately delete is still in pipeline).

NB. When clusterctl detect that you are trying to install a provider on top on an existing one (same provider/same namespace) it warns you with a message Installing provider %q can lead to a non-functioning management cluster (you can use --force to ignore this error): There is already an instance of the %q provider installed in the %q namespace

If you choose to force, clusterctl tries to do an upgrade instead of creating; TBH I don't know if it makes sense to try to make this smarter, given there is (there will be soon) a cleaner alternative (delete, re-install).

@vincepri @ncdc opinions ^^^

[ncdc]

I agree with what you wrote @fabriziopandini. What if we also get rid of --force?

[fabriziopandini]

I'm ok with that, but we should consider that clusterctl "blocks" init in the following cases

1. When installing a provider on top on an existing one (same provider/same namespace)
2. When installing a provider that is going to watch for objects in namespaces already controlled by other instances of the same providers
3. When installing two versions of the same provider

I'm ok in blocking (without possibility to force in 1,2). Probably we should drop 3, because after that recent changes this is not a problem anymore

[ncdc]

Agreed.

[fabriziopandini]

/lifecycle active