[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Proposal] new API for recover routers

Hi René,

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.

Dag Sonstebo
Cloud Architect

On 11/07/2018, 18:01, "Rene Moser" <mail@xxxxxxxxxxxxx> wrote:

    Hi Dag
    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