cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Wido den Hollander <w...@widodh.nl>
Subject Re: [DISCUSS] VR upgrade downtime reduction
Date Tue, 06 Feb 2018 12:32:00 GMT


On 02/06/2018 12:28 PM, Daan Hoogland wrote:
> I'm afraid I don't agree on some of your comments, Wido.
> 
> On Tue, Feb 6, 2018 at 12:03 PM, Wido den Hollander <wido@widodh.nl> wrote:
> 
>>
>>
>> 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.
>>
> ​expect add in a stop moment just before activating, that doesn't exist yet.
> ​

Ah, yes. But it would mean additional tests and parameters. Not that 
it's impossible though.

The VR is already fragile imho and could use a lot more love. Adding 
more features might break things which we currently have. That's my fear 
of working on them.

> 
> 
>>
>> 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.
> 
> ​all the scripts for rvr are already on the systemvm
> ​

Ah, yes, for the VPC, I forgot that.

> 
> 
>>
>>
>>
>>> ​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.
>>
> ​yes, it is.​
> 
> 
>>
>> 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 ;)
>>
> ​thanks for the input anyway, Wido

I think however that it's a valid point. The Redundant Virtual Router is 
mostly important when you have traffic flowing through it.

So for Basic Networking it's less important or for a setup where traffic 
isn't going through the VR and it only does DHCP, am I correct?

Wido

> ​
> 
> 
>>
>> Wido
>>
>>
>> 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] https://github.com/apache/cloudstack/pull/2435​
>>> [2] https://github.com/apache/cloudstack/pull/2436
>>>
>>>
> 
> 

Mime
View raw message