Re: [Proposal] new API for recover routers
I’ve seen both things happen – i.e. on rollback to old version (and with new VRs deleted) CloudStack management automatically started up new VRs, but also in other cases nothing happened and I had to do manual restarts.
So if I understand you correctly you would update http://cloudstack.apache.org/api/apidocs-4.9/apis/upgradeRouterTemplate.html to be more generic, i.e. do upgrade AND downgrade? I guess this could work.
On 11/07/2018, 18:01, "Rene Moser" <mail@xxxxxxxxxxxxx> wrote:
On 07/11/2018 12:08 PM, Dag Sonstebo wrote:
> Hi Rene,
> So if you have upgraded 4.5 to 4.11 (or any version upgrade where new system VM templates are in play) then your 4.5 VRs are by definition destroyed and you are running with 4.11 VRs. As a result there is nothing to recover – the rollback mechanism in this case is to roll back DB, destroy all 4.11 VRs (and anything else unknown to the original DB) – then start up the 4.5 management servers. At this point CloudStack management will either automatically build “new” 4.5 VRs – or worst case you do a network restart which recreates the VR.
Yes we know the procedure of the downgrade. The nice thing of the
upgrade is that the VR names stay as is and we thought it would be nice
if this would also be possible while "downgrading" or more precisely,
state="your VR are not in a version the running ACS supports --> recover
The thing is with "destroyed VR" hey are not coming back automatically,
do they? They are only be recreated on a e.g. network restart or an api
call related to a VR (user VM stop/start, etc.) right?
53 Chandos Place, Covent Garden, London WC2N 4HSUK