Octavia LBaaS - neutron-openvswitch issue with 'data-port'

[Lorenzo Cavassa]

Ubuntu 18.04
Rocky
Octavia ~next charm
Neutron OVS ~next charm

Description
===========

Deploying Octavia fails when related with an already deployed neutron-openvswitch service where the 'data-port' has been defined.

Here attached the error log got from the failing unit(s) and the overlay bundle used to deploy Octavia.

[Sahid Orentino (sahid-ferdjaoui)]

Hello Lorenzo,

Are you sure bond1 is well allocated on host, perhaps you could provide a list of the interfaces.

Thanks,
s.

[Sahid Orentino (sahid-ferdjaoui)]

Also the logs of OVS It may be interesting to see whether it reports errors.

[Frode Nordahl (fnordahl)]

I think a part of the issue here is how ``neutron-openvswitch`` handles non-existent interfaces.

I the OPs deployment ``neutron-openvswitch`` is used on both physical machines (for things like ``nova-compute`` and ``neutron-gateway``) and in containers (for Octavia).

The latter does not have a bond interface nor does it need any connection to a ``data-port``.

The charm should gracefully handle this allowing the configuration to be valid for both classes of services.

It does already provide a alternative input mechanism by listing white listed mac-addresses used to automatically resolve the data-port, but I guess this can be tedious for the deployer/operator in the case of all machines being equal except for a few units.

[Lorenzo Cavassa (lorenzo-cavassa)]

I deployed an additional 'neutron-openvswitch-octavia' subordinate charm just related with the Octavia service which hasn't any 'data-port' set and the deployment went good.
The next step it to activate Octavia to run some test of its LBaaS capabilities to check whether it really works in this configuration.

[Ryan Beisner (1chb1n)]

This seems to have a workaround, with more detailed config unblocking the deployment. Please update the bug, and the SLA level accordingly if this is the case (also confirm here). Thank you.

[Lorenzo Cavassa (lorenzo-cavassa)]

I can confirm the workaround (additional 'neutron-openvswitch-octavia' subordinate deployed and related with the Octavia units only - no 'data-port' set there) has worked properly.

I've updated the SLA.

[Edward Hope-Morley (hopem)]

I think that to allow the neutron-openvswitch charm to silently ignore interfaces that don't exist might introduce unexpected false negatives. Having said that, the behaviour would be inline with that of when mac addresses are used but none found for that host.

[Edward Hope-Morley (hopem)]

charm-helpers PR: https://github.com/juju/charm-helpers/pull/320

[OpenStack Infra (hudson-openstack)]

Fix proposed to branch: master
Review: https://review.opendev.org/658361

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.opendev.org/658361
Committed: https://git.openstack.org/cgit/openstack/charm-neutron-openvswitch/commit/?id=f7cfbe8bd33e9b1d2c3c99f1969292b665b3c580
Submitter: Zuul
Branch: master

commit f7cfbe8bd33e9b1d2c3c99f1969292b665b3c580
Author: Edward Hope-Morley <email address hidden>
Date: Fri May 10 14:29:10 2019 +0100

    Sync charm-helpers to get fix for PR 320

    Allows the charm to filter out interfaces from data-port
    that don't exist on the local host.

    Change-Id: I3a8ee204facf68753c564a297825666900c1b835
    Closes-Bug: #1822558