Open Stack

Hi All,

After gibi opened the neutron bug [1] I assigned it to myself and now
I got to summarize my plan to fix it. Please comment either in a reply
to this or in the bug report if you see problems, have questions, etc.

(1) Extend ovs and sriov agents config with
'resource_provider_hypervisors' for example:

ml2_conf.ini
[ovs]
bridge_mappings = physnet0:br-physnet0,...
resource_provider_bandwidths = br-physnet0:10000000:10000000,...
resource_provider_hypervisors = physnet0:hypervisor0,... # this is
new, values default to socket.gethostname() for each key in
resource_provider_bandwidths

sriov_agent.ini
[sriov_nic]
physical_device_mappings = physnet1:ens5,...
resource_provider_bandwidths = ens5:40000000:40000000,...
resource_provider_hypervisors = physnet1:hypervisor1,... # this is
new, defaults as above

The values for resource_provider_hypervisors are opaque identifiers
for neutron. Since each physical device can have its own hypervisor
associated possible features like ovs-superagent (for smartnics) could
be supported. Use of socket.gethostname() is only hardcoded as a
default, so non-libvirt hypervisors are taken care of.

(2) Extend the report_state message's configurations field alike:

{
'bridge_mappings': {'physnet0': 'br-physnet0'},
'resource_provider_bandwidths': {'br-physnet0': {'egress': 10000000,
'ingress': 10000000}},
'resource_provider_hypervisors': {'br-physnet0': 'hypervisor0'},
'resource_provider_inventory_defaults': {'allocation_ratio': 1.0,
'min_unit': 1, 'step_size': 1, 'reserved': 0}
}

Do not touch the host field of the same message.

Since we always treated the configurations field as free format, IMO
changes to it should be backportable. Let me know if you think
otherwise.

(3) In neutron-server

report_state.host is used in binding as now - no change here.

report_state.configurations.resource_provider_hypervisors.PHYSDEV to
be used in selecting parent resource provider for agent and physdev
RP-tree. When not available in the message still fall back to using
report_state.host as today.

(4) At the moment I don't see the need to use the proposed new nova
API to query hypervisors managed by a nova-compute since as soon as it
returns 1+ hypervisors neutron cannot do anything with the result.

Cheers,
Bence

[1] https://bugs.launchpad.net/neutron/+bug/1853840