<html> <head> <meta content="text/html; charset=utf-8" http-equiv="Content-Type"> </head> <body bgcolor="#FFFFFF" text="#000000"> <div class="moz-cite-prefix">On 11/11/14 16:44, Mark Shuttleworth wrote: </div> <blockquote cite="mid:54623CE4.5020201@ubuntu.com" type="cite"> That's right. Networking is under active development this cycle </blockquote> 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 play: <ul> <li>As of today, Juju+MAAS+LXC supports only one network (eth0 bridged onto host's br0)</li> <li>During this development cycle it expected that that limitation will be lifted. </li> <li>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.</li> <li>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).</li> <li>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). </li> </ul> 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 forward. 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 <pre class="moz-signature" cols="72">-- ----------------------------- John McEleney Netservers Ltd. 21 Signet Court Cambridge CB5 8LA <a class="moz-txt-link-freetext" href="http://www.netservers.co.uk">http://www.netservers.co.uk</a> ----------------------------- Tel. 01223 446000 Fax. 0870 4861970 ----------------------------- Registered in England Number: 04028770 ----------------------------- </pre> </body> </html>