Comment 6 for bug 1843497

Hello!

Sorry for the delay. Yes, this cluster had been 2.3 at one point, though it was already on 3.0.17 when this upgrade began.

I agree regarding what needs to happen. The one thing I would point out is that there are existing deployments in this state... having a 3.0.17 DB, but it living in etcd0.etcd... so whatever solution is used needs to account for that state.

Also - I think the regeneration of the config is the core issue here, because the cluster token was lost as well, so even if the data had been moved, the cluster would not have recovered because the token was different. Perhaps the token could be generated from the juju identifiers somehow, so it is always consistent.