When in a subordinate relation with neutron-gateway, breaks the latter

[Florian Haas]

This is not so much actually a bug, but rather a design issue that makes it very easy for people to break something, with an innocent mistake, in a way that is rather difficult to recover from.

This charm is meant to be subordinate only to nova-compute, not to neutron-gateway. However, due to the way subordinate charms are wired, it is *possible* to build such a relationship with a simple

juju add-relation neutron-openvswitch neutron-gateway

When neutron-openvswitch thus becomes subordinate to neutron-gateway, the neutron-gateway node oscillates between having neutron-dhcp-agent, neutron-vpn-agent and neutron-metadata-agent installed (neutron-gateway) and uninstalled (neutron-openvswitch), depending on which charm Juju is currently handling.

Needless to say, this puts the user in a world of pain. Pretty much all their networking will break, and there is no way to remove a subordinate charm relationship other than killing and redeploying the principal charm altogether. Since neutron-gateway is deployed to the bare metal, rather than a container, this means a physical re-installation, which even with MAAS can be painfully time-consuming. And until such a redeployment has completed, their cloud is largely non-functional.

I don't have a particularly good suggestion on how this could be addressed, other than perhaps teaching the principal charm a blacklist of charms it does *not* want as subordinates. Any other ideas?

[James Page (james-page)]

I think this might actually be quite trivial to resolve; the nova-compute integration uses a explicitly declared container scoped relation; the reason its possible to relate neutron-openvswitch to neutron-gateway is due to the additional:

  requires:
    container:
      interface: juju-info
      scope: container

relation declared which is superfluous - we should be able to drop this at which point:

$ juju add-relation neutron-openvswitch neutron-gateway
ERROR no relations found

[Florian Haas (fghaas)]

Thanks. Of course, it would actually be quite intuitively logical for
this charm to be subordinate to neutron-gateway, and it would probably
save a lot of code duplication if it were done that way. But as it is,
creating the subordinate relation *seems* to work but actually royally
messes things up, so yes, dropping the relation altogether is probably
the superior option.

[James Page (james-page)]

Some of that's historical; neutron-gateway preceeded neutron-openvswitch by quite some time, and although the nova-compute integration has been refactored to work this way, the neutron-gateway charm is still on the TODO list; we're generally taking the approach of splitting out l2 management for any SDN provider into a subordinate charm in this way.