cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Wido den Hollander <>
Subject Re: [DISCUSS] VR upgrade downtime reduction
Date Tue, 06 Feb 2018 11:03:30 GMT

On 02/05/2018 04:44 PM, Daan Hoogland wrote:
> H devs,
> I have recently (re-)submitted two PRs, one by Wei [1] and one by Remi [2],
> that reduce downtime for redundant routers and redundant VPCs respectively.
> (please review those)
> Now from customers we hear that they also want to reduce downtime for
> regular VRs so as we discussed this we came to two possible solutions that
> we want to implement one of:
> 1. start and configure a new router before destroying the old one and then
> as a last minute action stop the old one.

Seems like a simple solution to me, this wouldn't require a lot of 
changes in the VR.

> 2. make all routers start up redundancy services but for regular routers
> start only one until an upgrade is required at which time a new, second
> router can be started before killing the old one.​

True, but that would be a problem as you would need to script a lot in 
the VR.

> ​obviously both solutions have their merits, so I want to have your input
> to make the broadest supported implementation.
> -1 means there will be an overlap or a small delay and interruption of
> service.
> +1 It can be argued, "they got what they payed for".
> -2 means a overhead in memory usage by the router by the extra services
> running on it.
> +2 the number of router-varieties will be further reduced.
> -1&-2 We have to deal with potentially large upgrade steps from way before
> the cloudstack era even and might be stuck to 1 because of that, needing to
> hack around it. Any dealing with older VRs, pre 4.5 and especially pre 4.0
> will be hard.

I don't like hacking. The VRs already are 'hacky' imho.

We (PCextreme) are only using Basic Networking so for us the VR only 
does DHCP and Cloud-init, so we don't care about this that much ;)


> I am not cross posting though this might be one of these occasions where it
> is appropriate to include users@. Just my puristic inhibitions.
> Of course I have preferences but can you share your thoughts, please?
> ​
> ​And don't forget to review Wei's [1] and Remi's [2] work please.
> ​[1]​
> [2]

View raw message