cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From sebgoa <>
Subject Re: VPC Virtual Router and Redundancy
Date Mon, 14 Jul 2014 07:51:57 GMT

On Jul 14, 2014, at 9:38 AM, Hugo Trippaers <> wrote:

> Hey All,
> As discussed in thread some of us are working
on making the VPC virtual router redundant. As part of this effort we are doing just a little
bit more to get this properly done. Based on the feedback we at Schuberg Philis are getting
from our colleagues we have identified a list of design goals that we would like to improve
in the vpc virtual router, the most important of those are :
> * reboot proof, making sure that the router will come up with the proper configuration
after a reboot without management server intervention
> * redundant, the VPC router should be able to fail-over to another device with minimum
possible interruption to the service
> * introduce the new features with a smooth upgrade path for existing deployments

+1 to a wiki page 'design documents' that describes this feature in a bit more details 

…like all other features...

> We are working on this with a team of developers, some of which are committers and some
of which are not. So we will be working in a github repository most of the time. If you wish
to keep an eye on what we are doing check the branches starting with vpc-toolkit at
> When possible we will commit completed parts to a feature branch or the master branch
to make sure we don’t diverge to much from that actual state of things.
> We are currently doing a number of experiments on how to achieve our design goals and
at the same time we are working on making the code a little more legible by refactoring some
of the components like the VirtualNetworkApplianceManager and the VirtualRoutingResource.

> Our current thinking is to persist configuration state on the virtual router device (the
actual vm) and configure the VR baed on that configuration. We intend to put most of the configuration
in json files on the template and use either configuration management tools or custom scripts
to do the configuration. A typical command implementation would take two steps. First push
an update to a configuration file and then trigger an update script. 
> Of course an important part of everything we are doing will include testing, we are already
working on improving the existing unit tests for the VR and VPC code and we are setting up
a procedure to test the systemvm configuration scripts as well.
> We’ll do more updates like this to the list as we make progress. 
> Cheers,
> Hugo

View raw message