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 <w...@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
