Updated Openstack charms broke our HA

[John McEleney]

On 11/11/14 12:59, Mark Shuttleworth wrote:
> I think you've hit on one of the weaknesses of the charm ecosystem,
> which is that one needs to "know how to use them" if one wants to get
> beyond one-service-unit-per-machine. We can either encourage charmers to
> invest in better documentation (a good place to start) or we can
> encourage the charmers to bake more of this sort of operating
> intelligence into bundles (we have some preliminary examples of that in
> cloud foundry, where the bundle becomes "intelligent" and does this sort
> of thing for you) or we can identify some common patterns and socialise
> those across charmers so that one only has to stub one's toe on this
> sort of problem once.

I think there's some blurring of lines between the roles played by MAAS,
Juju and charms in this area. Thinking about it I think that Juju and
Juju's driver for MAAS is the area where this mysterious multi-NIC HA
set-up resides, rather than this being charm related.

Correct me if I'm wrong, but this is how I understand the roles:

  * MAAS acts as a cloud provider for Juju.
  * MAAS itself is concerned only with bare metal, and getting a OS
    installed with the requisite SSH key(s) deployed.
  * LXC containers are not strictly-speaking a function of MAAS, but are
    actually created by an agent that Juju deploys on the host system
    after the handover from MAAS.
  * If a charm/service requires a connection to a certain Layer-2
    network, then this must be a Layer-2 network that physical MAAS
    nodes can connect to. In a single network scenario, this is simply
    the network attached to "br0".
  * Charms themselves are cloud-provider agnostic. They don't care if
    you use MAAS+LXC, KVM or EC2. The actual vip/HA code within the
    charm simply examines the local environment searching for NICs that
    match the subnet of the vip it wishes to bind.
  * For the Openstack charms to have access to multiple NICs, the cloud
    platform on which it resides (in this case MAAS via the Juju agent)
    must have created a container that has two NICs.
  * Juju (not MAAS, or the charm) is responsible for instantiating the
    LXC container on the physical host with two NICs which are bridged
    to the requisite networks.

If what I've said above is right then my question regarding how LXC
machines can be instantiated with two NICs connected to two pre-existing
VLANs is a question for Juju developers. I don't think that the creation
of the container is something that charmers need concern themselves with.

The real blurring of lines here is the that the "cloud provider" (if
defined as the creator of LXC containers) is not MAAS, but is really
Juju's agent deployed on a MAAS-provisioned physical host.

Does that all sound right?

If so, who do I need to converse with, or what material is there to read
that explains how one is intended to deploy OpenStack Charms in a HA
manner, utilising two distinct Layer-2 networks?

Thanks,
John

-- 
-----------------------------
John McEleney
Netservers Ltd.
21 Signet Court
Cambridge
CB5 8LA
http://www.netservers.co.uk
-----------------------------
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/b7b6b5e9/attachment.html>