opened
vincepri
username_0
/kind feature

**Describe the solution you'd like**
This is a counter-proposal to #1187. For v1alpha2 we can remove all the pivoting logic and only support management clusters. If this issue is accepted, the CLI becomes a toolkit of alpha phases to create and delete clusters without higher level abstraction
Remove pivoting logic from clusterctl
issue
created
moshloop
username_1
Is a pivot not conceptually the same as a backup and restore? 

I am in favour of removing both pivot and bootstrapping so the existing pivot workflow would be transformed to:

1) Create kind/minukube/management cluster (out of band)
2) `clusterctl create cluster`
3) Backup and restore CAP* objects to target cluster (out of band)
comment
created
vincepri
username_0
/area clusterctl
comment
created
detiber
username_2
@username_1 pivot is indeed basically a backup/restore, but that backup/restore needs to be done in a certain order (and ensuring that only a single set of controllers is operating for a given set of objects) to ensure a successful migration.
comment
created
sethp-nr
username_3
We're pretty active users of the pivot functionality, and so if it were removed from `clusterctl` that would at least delay our adoption of the v1alpha2 components.

We really like the conceptual fit for our users (use `kubectl` to scale your cluster!) and the failure isolation it provides (if you scale all the machine deployments to zero, only your cluster will be affected!). We'd need to take some time to figure out what to do to preserve/recover those benefits.
comment
created
ncdc
username_4
Google doc for a gap analysis: https://docs.google.com/document/d/1YWO6nyLToSn7vuwLfbMpvXKU7IVO8FhFApRZIdFShH0/edit#
comment
created
vincepri
username_0
Closing in favor of #1187

/close
comment