Comment 5 for bug 1839300

Unfortunately, I need to re-open this bug.

The nova-compute and neutron-openvswitch charms are not looking up the same interface ip's FQDN hostname causing placement issues in neutron-api/ovs such as:

2019-12-30 22:22:13.095 503444 DEBUG neutron.plugins.ml2.drivers.mech_agent [req-f928aab6-4685-4bea-af59-ad115b952cbf 5580199fdfc343fcb3c41fb8636ea6c8 c80a5b62cfe6435ab44315de3d670b2f - 3ef3cedadd5a4331a11118211060834e 3ef3cedadd5a4331a11118211060834e] Port d54c0eaf-0f35-4e8f-abe3-bb9ca646107f on network a7afdf47-4eaf-4fe3-8a7d-97c4e2a8e4e1 not bound, no agent of type HyperV agent registered on host bond1.713.myhost1.maas bind_port /usr/lib/python3/dist-packages/neutron/plugins/ml2/drivers/mech_agent.py:104
2019-12-30 22:22:13.096 503444 ERROR neutron.plugins.ml2.managers [req-f928aab6-4685-4bea-af59-ad115b952cbf 5580199fdfc343fcb3c41fb8636ea6c8 c80a5b62cfe6435ab44315de3d670b2f - 3ef3cedadd5a4331a11118211060834e 3ef3cedadd5a4331a11118211060834e] Failed to bind port d54c0eaf-0f35-4e8f-abe3-bb9ca646107f on host bond1.713.myhost1.maas for vnic_type normal using segments [{'id':
22:26 <drewn3ss> '92f10021-2981-4d37-a027-4b0a9ffbfc37', 'network_type': 'vxlan', 'physical_network': None, 'segmentation_id': 1064, 'network_id': 'a7afdf47-4eaf-4fe3-8a7d-97c4e2a8e4e1'}]

When I investigated the code changes, nova-compute uses:
         host_ip = get_relation_ip('cloud-compute',
                                   cidr_network=config('os-internal-network'))

but neutron-openvswitch uses:
        host_ip = get_relation_ip('neutron-plugin')

When I dump my bindings for my model, here is a subsection of the nova-compute bindings:

nova-compute:
    bindings:
      "": internal-space
      cloud-compute: internal-space

Here are all of the neutron-openvswitch bindings:
    bindings:
      data: internal-space

Oddly, I don't see bindings called out for "" or neutron-plugin. This may be an export-bundle shortcoming for subordinate charms.

I do see in the metadata.yaml for charm-neutron-openvswitch that the neutron-plugin binding is the local container relation. Since that's local container relation, what would that default binding IP be? localhost? Is this triggering some sort of fall-back methodology?

Ultimately, when I look in openstack services, I see that openstack compute service list has "bond1.713.myhost1.maas" as the nova-compute host, and openstack network agent list has the ovs agent on the node "myhost1.maas".

I'd prefer both to be myhost1.maas and not rely upon the IP address for the interface on the binding, but I can understand use cases where a specific FQDN may be needed vs the hosts' primary hostname/fqdn.

Ultimately, the fix needs to result in the same FQDN between both nova-compute and neutron-openvswitch, which means nova-compute probably has to provide the fqdn to ovs over it's relation as there may be many reasons they'd not be able to share a binding that would result in the same hostname.