cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Leo Simons <LSim...@schubergphilis.com>
Subject Re: VPC Virtual Router and Redundancy
Date Mon, 22 Sep 2014 10:27:11 GMT
Hey all,

High time for an overview/update on this...

Refactoring of the systemvm build process
====
@see https://github.com/apache/cloudstack/pull/16

This should be about ready to merge now. Rohit helped port to buildacloud.org and is now testing
it on KVM, and will apply the pull if those tests pass. It was a prerequisite for...

Component testing for the systemvm
=====
@see https://github.com/schubergphilis/cloudstack/tree/feature/systemvm-test

I have not submitted a pull request for this yet, because it currently still depends on downloading
images from our internal infrastructure — but once the build refactor is merged in, and
the main builds are updated to use it, we can register those builds with vagrantcloud.com
and then this can be merged too.

Integration tests using the modified systemvm
=====
@see http://markmail.org/message/zjhjwky3god6d25i

I showed this work to Ian, Rohit and Wido last week. We’re having some (infrastructure)
issues getting these tests stable so it’s not quite ready for open sourcing. However since
it’s taking a bit longer than I wanted I’ll look into getting the code opened up anyway.

Reboot proof systemvm
=====
@see https://github.com/schubergphilis/cloudstack/tree/feature/systemvm-persistent-config
@see http://markmail.org/message/n4sohmhowzm244iq

We’re at the point now where we are probably pretty happy with how this looks. update_config.py...

  https://github.com/schubergphilis/cloudstack/blob/feature/systemvm-persistent-config/systemvm/patches/debian/config/opt/cloud/bin/update_config.py

is becoming the sole entry point to making network-related systemvm configuration changes.
It’s a wrapper around configure.py...

  https://github.com/schubergphilis/cloudstack/blob/feature/systemvm-persistent-config/systemvm/patches/debian/config/opt/cloud/bin/configure.py#L974

Many of the networking changes are now done by uploading a JSON configuration describing the
desired state, and then executing this script to converge the systemvm to the desired state.
This makes the lower layers on the java side of changing the systemvm look rather neater too,
for example

  https://github.com/schubergphilis/cloudstack/blob/e82bfb410b758dce372c4203febecb373880594b/core/src/com/cloud/agent/resource/virtualnetwork/ConfigHelper.java#L102

There’s component tests for this new way of applying config changes

  https://github.com/schubergphilis/cloudstack/blob/feature/systemvm-persistent-config/test/systemvm/test_update_config.py

and those make us pretty hopeful all the changes are correct. However, we need to spend more
time on integration testing, to test the end result is still behaving exactly as it should
and everything is fully backward compatible.

VPC java code refactoring
=====
@see https://github.com/apache/cloudstack/pull/19
(old https://github.com/apache/cloudstack/pull/18
     https://github.com/apache/cloudstack/pull/14)

I suggest reading the pull requests for details...this is meant to be a fully backwards-compatible
code cleanup that’s independent of the other changes mentioned above. We wanted to get unit
test coverage up on this code before making functional changes to it, working to de-duplicate
vpc and non-vpc networking code as much as possible. We ended up introducing a pretty neat
new router deployment definition setup.

Redundant routing
=====
With these two tasks pretty much out of the way, while we still have a bunch of integration
testing to finish, we’re now also starting in earnest on making the result actually redundant.

We’re getting the ‘building blocks’ for redundancy (vrrp, heartbeat, ...) into the configure.py
framework

  https://github.com/schubergphilis/cloudstack/commit/c95f5e208640f49a9f1855a7976ff0518184bdf1

and after that we’ll probably spend a bit of time experimenting with how to best put them
together. Once that design solidifies (though I imagine it will not deviate much from the
previous discussions we had on #cloudstack-meeting) it’ll be time for another update :-)


cheers,


Leo

On Jul 14, 2014, at 9:38 AM, Hugo Trippaers <hugo@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
> 
> 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
> 


Mime
View raw message