Comment 3 for bug 1459567

Ignoring any detailed review of the charms for the moment, I'd like to review the high-level design for the PLUMgrid integration into OpenStack.

Specifically neutron-iovisor and neutron-plumgrid-plugin seem very confusing right now.

1) neutron-plugin-plumgrid

The neutron-api charm does not (yet) declare a container scoped relation for configuration of core plugin configuration in a neutron deployment, so the metadata.yaml for neutron-plumgrid-plugin is not valid.

The current way to integrate a plugin into neutron-api is to change that charm directly - one of my team is working on adding a feature to the neutron-api charm via a container scoped interface so plugins + associated config and relations can be pushed out into a sub-oridnate charm - so if we can park that for a few weeks, it would save a-lot of rework right now.

I’d also like to understand whether this charm is doing anything other than configuring the neutron-api service to point at plumgrid-director? Normally the neutron-api service is deployed and scaled in LXC containers - doing anything like loading kernel modules or running networking services is not going to fit well if that is required here.

2) neutron-iovisor

I *think* neutron-iovisor is trying to perform the same type of role as the neutron-openvswitch charm (configuration of L2 networking services on nova-compute nodes) - in which case it needs to be a suboridinate charm and must have the following interface to allow it to deploy and scale with the nova-compute charm:

 provides:
  neutron-plugin:
    interface: neutron-plugin
    scope: container

both of the above charms declare:

provides:
  plumgrid-plugin:
    interface: plumgrid-plugin

which does not look right to me. I think the core interface + charm design might need to look more like this:

<plumgrid-gateway>
  requires:
    plumgrid:
     interface: plumgrid

<plumgrid-edge>
  requires:
    plumgrid:
     interface: plumgrid

<plumgrid-director>
  provides:
    plumgrid:
     interface: plumgrid

you can probably drop the plumgrid-plugin interface - see below

<neutron-api>
   <neutron-plugin-plumgrid> (see note above about this not being supported yet)
 provides:
   plumgrid-plugin:
     interface: plumgrid-plugin

maybe this should be:

  requires:
    plumgrid:
     interface: plumgrid

<nova-compute>
    <neutron-iovisor> (maybe rename this neutron-plumgrid?)

The charm must have the following interface to allow deployment with nova-compute:

  provides:
    neutron-plugin:
      interface: neutron-plugin
      scope: container

maybe this should also have:

  requires:
    plumgrid:
     interface: plumgrid

I would expect the ‘plumgrid’ interface to allow the plumgrid director to pass:

  director_ip
  director_port
  director_admin_username
  director_admin_password

as this seems to be the pertinent information required to configure and access the director - this as then used by all other services to configure/connect.