cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Paul Angus <paul.an...@shapeblue.com>
Subject RE: [DISCUSS] VR upgrading workflow thoughts
Date Tue, 03 Apr 2018 06:53:49 GMT
Hi Rene,


I have a wishlist item that hoped to improve the upgrade process.  A GSOC guy (Rohit Vavaldas)
 has picked it up for his project this year.
https://issues.apache.org/jira/browse/CLOUDSTACK-10262

wrt to your vision - backwards compatibility of the system VR templates would be great - but
I fear that the burden on the community to do this would too big.
I guess that we would need to re-architect VR comms to go through a single 'well and strictly
described' interface, which can cope with receiving arguments that it doesn’t understand..
 (sorry for the very bad top-off-the head description).

It would be awesome if we could do it though.




paul.angus@shapeblue.com 
www.shapeblue.com
53 Chandos Place, Covent Garden, London  WC2N 4HSUK
@shapeblue
  
 


-----Original Message-----
From: Rene Moser <mail@renemoser.net> 
Sent: 02 April 2018 17:33
To: dev@cloudstack.apache.org
Subject: [DISCUSS] VR upgrading workflow thoughts

Hi

One of the biggest challenges in cloudstack is upgrading VRs in an advanced networking setup.

Even though with the latest efforts made by shapeblue and Rohit (nice
work) the replacement of a VR does not disconnect the services behind the router anymore,
there is still room for improvement.

Currently, the issue we still face for clouds in production using advanced networking is,
a valid roll back path.

Today upgrade path works like this (correct me when I am wrong)

1. upload new template
2. upgrade management service
3. rolling out new VRs

The issue is, the VRs can not be fully used until upgraded (new instances, new firewall rules
etc, are not possible)

Our vision is that a new VR template would also be compatible with previous version of cloudstack
management service. This would allow to rolling out new VRs using _before_ upgrading the management
service:

1. upload new template
2. rolling out new VRs
3. upgrade management service

What are the benefits of this?

It would allow to test the VRs before the management service upgrade and roll back to previous
template (or upload a fixed template) in case of issues.

A rollback of the management service would not necessarily result in redeployment of VRs as
they were still compatible.

Any thoughts?











Mime
View raw message