Comment 6 for bug 1459567

Hi Bilal

"@James on Neutron-plumgrid-plugin charm: Neutron-api charm allows a neutron plugin to declare only one template file in charmhelpers/contrib/openstack/neutron.py whereas PLUMgrid plugin needs to write two files inside the neutron container. I have created a sub-ordinate charm for this and am successfully getting relation data from the neutron-api charm through the container-relation hook. I do not require any change in the neutron-api charm for this to work either.
My aim has been to keep the changes required in the neutron-api charm to bare minimum so that it is easier to get them merged over there. (https://code.launchpad.net/~bbaqar/charms/trusty/neutron-api/next)"

I was surprised this works - it actually feels like a bug in Juju as the definition in neutron-api is:

  provides:
    neutron-plugin-api:
      interface: neutron-plugin-api

and neutron-plugin-plumgrid declares:

  requires:
    container:
      interface: neutron-plugin-api
      scope: container

I *thought* that both ends of a relation had to have the same scope - but I may be wrong! I'll check with the Juju team.

RE https://code.launchpad.net/~bbaqar/charms/trusty/neutron-api/next - I'd still like to understand why your proposing to provide access to the plumgrid director via configuration and not a relation - as plumgrid-director is charmed, this seems like an obvious thing todo.

"The charm is just installing deb packages that are required in the neutron-container to talk to pg-director and writing a file to pass on keystone auth token to get admin data. The kernel module is being installed and loaded in neutron-iovisor charm. Therefore it is totally safe for this charm to scale in lxc containers."

Great - thanks for confirming.

"@James on Neutron-iovisor charm: The problem with having neutron-iovisor charm as a subordinate charm is that we need iovisor on nodes other than compute itself. Also our director, edge and gateway charms need to be deployed to the same container as the iovisor charm but once again i can't declare any of them as a subordinate charm as all three of them are deployed in an environment to provide our complete solution. I understand that this doesn't go well with the charms ideology of containerization but its a limitation for us and that is the only we can do it in my knowledge."

What's the scope of having this charm deployed by itself? I'd like to understand the use cases.

Do the director, edge and gateway charms get deploy on separate servers normally or do they all reside on a single server.

An understanding of both the logical and physical deployment structure would be useful.