You are viewing a plain text version of this content. The canonical link for it is here.

Posted to dev@cloudstack.apache.org by Rene Moser <ma...@renemoser.net> on 2018/07/11 09:49:35 UTC

[Proposal] new API for recover routers

Hi

While tested v4.11.1 in the lab and upgraded the routers, we came across
the need of "downgrade" the routers after rolled back to ACS to v4.5
(testing upgrade process).

So my proposal is to have a new api for recover the routers to the
system-vm template, AFAICS similar to
https://cloudstack.apache.org/api/apidocs-4.11/apis/recoverVirtualMachine.html
but for routers.

Any thoughts?

Regards
René

Re: [Proposal] new API for recover routers

Posted by Dag Sonstebo <Da...@shapeblue.com>.

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.

Regards,
Dag Sonstebo
Cloud Architect
ShapeBlue

On 11/07/2018, 18:01, "Rene Moser" <ma...@renemoser.net> 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
them"

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?

Regards
René

Dag.Sonstebo@shapeblue.com
www.shapeblue.com
53 Chandos Place, Covent Garden, London WC2N 4HSUK
@shapeblue

Re: [Proposal] new API for recover routers

Posted by Rene Moser <ma...@renemoser.net>.

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
them"

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?

Regards
René

Re: [Proposal] new API for recover routers

Posted by Dag Sonstebo <Da...@shapeblue.com>.

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.

If you haven’t upgraded the VRs – and they are still running as version 4.5 under a 4.11 management server – then the rollback is a straight forward DB rollback and management restart – the original VRs will stay in place.

Regards,
Dag Sonstebo
Cloud Architect
ShapeBlue

On 11/07/2018, 10:49, "Rene Moser" <ma...@renemoser.net> wrote:

    Hi
    
    While tested v4.11.1 in the lab and upgraded the routers, we came across
    the need of "downgrade" the routers after rolled back to ACS to v4.5
    (testing upgrade process).
    
    So my proposal is to have a new api for recover the routers to the
    system-vm template, AFAICS similar to
    https://cloudstack.apache.org/api/apidocs-4.11/apis/recoverVirtualMachine.html
    but for routers.
    
    Any thoughts?
    
    Regards
    René
    
    


Dag.Sonstebo@shapeblue.com 
www.shapeblue.com
53 Chandos Place, Covent Garden, London  WC2N 4HSUK
@shapeblue