Re-introduce v0.19 of vCluster #160
Conversation
|
sigh we'll need a breaking change flag in the CRD to prevent auto upgrade from doing bad things then |
|
Would it not make more sense to have 1.0.0 left as We can "turn off" sync for the dev cluster, bump the cluster mangaer up and then resync which will leave that one as it is and then it means that prod needs no action essentially? Not sure if that is feasible of course but might be the safer approach to do it on dev rather than making a potentially breaking change action to prod? |
|
Yeah it's six of one, half a dozen of the other since we'd have the opposite problem in dev. Let's discuss remediation in Slack. |
yankcrime
force-pushed
the
vcluster_019
branch
from
7cd0674 to
d70fbe0
Compare
Essentially revert 14e70f2, but introduce a new clustermanagerapplicationbundle version so that existing Cluster Managers can still be managed without having to be destroyed.
yankcrime
force-pushed
the
vcluster_019
branch
from
d70fbe0 to
d9a51a7
Compare
|
Okay, here's how it's gonna go down. The vcluster upgrade was a breaking change, and we don't want that kind of accident to happen in production causing irreparable damage. As I say, auto upgrade is a problem here that needs solving, as per #162. So you have two options, You can either have one bundle as Which you select is up to you, and will probably be dependent on which is going to cause the least pain... said pain means that some cluster managers will need to be manually updated to a non-existent bundle version (this will error and cause no harm), then you can perform the upgrade and they'll start reconciling again. Given the new vcluster has been in the wild for a relatively long time now, I'd suggest reinstating the old vcluster as a |
|
Closing in favour of an alternative approach. |
Essentially revert 14e70f2, and introduce a new clustermanagerapplicationbundle version so that existing Cluster Managers can still be managed without having to be destroyed.