On Jul 14, 2014, at 9:38 AM, Hugo Trippaers <h...@apache.org> wrote:
> Hey All, > > As discussed in thread http://markmail.org/message/56xrscvnmdweoxf5 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 > https://github.com/schubergphilis/cloudstack/commits/vpc-toolkit > > 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 >
