Updated Openstack charms broke our HA

John McEleney john.mceleney at netservers.co.uk
Tue Nov 11 18:02:57 UTC 2014

On 11/11/14 16:44, Mark Shuttleworth wrote:
> That's right. Networking is under active development this cycle 

OK, so maybe I'm getting a bit ahead of myself when it comes to how LXC
networking works today. Maybe things are unclear simply because the
feature-set is in a state of flux right now.

I'm seeing functionality in the charms (support for multiple NICs+vips)
that are apparently not supported today by LXC containers.

In the interest of clarity, this seems to me to be the current state of

  * As of today, Juju+MAAS+LXC supports only one network (eth0 bridged
    onto host's br0)
  * During this development cycle it expected that that limitation will
    be lifted.
  * Today charms support multiple vips+NICs, but until Juju-LXC
    development catches up, you can only realistically deploy one
    network and one vip per LXC container.
  * Given that the Pacemaker config code within the charms can only bind
    vips to NICs that already have IPs in the same subnet, and given a
    requirement that vips should be public IPs, that means that all LXC
    nodes require public IP addresses (assigned by DHCP).
  * Later on this cycle when multiple NICs in LXC are implemented, and
    it become possible to run two Layer-2 networks, back-end servers
    that do not strictly need a public IP (such as MySQL or RabbitMQ)
    can be hosted exclusively on a private LAN (using RFC1918 addresses).

If all of that is true, I think I'll stick to patching the charms to
support the old vip_cidr and vip_iface type behaviour for the time
being. That way I can stick with only deploying public IPs where they
are strictly required. I'll revisit this at a later date when the
multi-network functionality has matured.

I don't like straying from the well trodden path (patching), so it would
be good know what Ubuntu's best-practices are going to look like going

I think that this IP address conservation issue deserves some attention.
The scale-out potential of OpenStack services is practically infinite.
However, they can only be scaled-out if there are sufficient IP
addresses available to support them. The finite resource of public IPv4
addresses is a poor fit for a scale-out model. This is not an issue if
we only deploy public IPv4 when strictly needed. This is achievable, and
something that we have done with ease with the old charms.

As I say, it would be good to know what Ubuntu/Canonical view as best
practice in this area.


John McEleney
Netservers Ltd.
21 Signet Court
Tel. 01223 446000
Fax. 0870 4861970
Registered in England
Number: 04028770

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/juju/attachments/20141111/bb576c22/attachment.html>

More information about the Juju mailing list