octavia should be in VM or disabe enable-local-dhcp-and-metadata

[Narinder Gupta]

In openstack deployment if we enabled octavia in lxd containers and enable enable-local-dhcp-and-metadata causes subnets dhcp and metadata agents down.

Scenario:
Deploy openstack with octavia in container with enable-local-dhcp-and-metadata=true with neutron-openvswitch. Create mutiple subnets observed that subnet dhcp agent and metadata services were down.

We saw neutron created the dhcp on the octavia units which causes dhcp agents not to respond.

Solution:
1) do not enable enable-local-dhcp-and-metadata
2) convert the containers into VM.

Discussion is required and appropriate action has to be taken in this regard.

[Frode Nordahl (fnordahl)]

The ``neutron-openvswitch`` charm needs to learn to deal with being deployed in a container differently than if it is on bare metal/in a VM.

As a workaround you can deploy a separate instance of ``neutron-openvswitch`` application in your Juju model for use with Octavia. That will let you set up the neutron-openvswitch application used on metal as you see fit without impacting the octavia units.

[Chris MacNaughton (chris.macnaughton)]

I'm marking these as invalid/triaged on the idea that this needs to be resolved in the OVS charm by better handling being inside of a container. Additionally, it may be a better solution to, as Frode points out, deploy an additional OVS charm to reside with Octavia.

[James Page (james-page)]

DVR, L3HA and enablement of metadata and local dhcp services are all now guarded with:

  not is_container()

[James Page (james-page)]

However I expect there is a load more that still needs to be guarded - DPDK and SR-IOV being two immediate features that spring to mind but won't work when deployed inside a container.

As we have a workaround (deploying a separate n-ovs instance without options enabled) I'm requesting that we drop field-high from this bug - maybe subscrib field-medium to keep it tracked longer term?