Previously we assumed that we can look up the resource provider (created
by nova) to be used as the parent of the agent and physical NIC resource
provider tree by the name set in the config option DEFAULT.host. This
assumption was wrong.
While nova-compute's DEFAULT.host and neutron-agent's DEFAULT.host
must match for port binding to work, the root resource provider created
by nova does not belong to the compute host (where nova-compute runs)
but it belongs to the compute nodes (i.e. hypervisors). Actually there
may be multiple compute nodes managed by a single nova-compute (think
of ironic). Plus the value of DEFAULT.host and the compute node's ID
may be different even when nova-compute manages a hypervisor on the
same host because of various deployment considerations. For example
when tripleo does not manage the undercloud (so a libvirt hypervisor
returns the plain hostname), but the same tripleo enforces it's host
naming conventions in nova's and neutron's DEFAULT.host settings.
This change enables neutron to use the hypervisor name to locate the
root of the resource provider tree.
We introduce a new configuration option for
(1) ovs-agent: resource_provider_hypervisors, for example:
For both agents 'resource_provider_hypervisors' values default to
socket.gethostname() for each key in resource_provider_bandwidths.
We try to not block later developments in which one neutron
agent may manage devices on multiple hosts. That's why we allow
the each physdev to be associated with a different hypervisor.
But here we do not try to solve the problem that the natural physdev
identifiers may not be unique accross multiple hosts. We leave solving
this problem to whoever wants to implement an agent handling devices of
multiple hosts.
(3) We extend report_state message's configurations field alike:
(4) In neutron-server we use
report_state.configurations.resource_provider_hypervisors.PHYSDEV
when selecting parent resource provider for agent and physdev
RP-tree. When not available in the message we fall back to using
report_state.host as before.
Since we only changed the free-format configurations field of the
report_state message rpc version is not bumped and we expect this
change to be backported to stein and train.
Reviewed: https:/ /review. opendev. org/699196 /git.openstack. org/cgit/ openstack/ neutron/ commit/ ?id=b99dee2df60 45e5fe0896acefc 591798953d375d
Committed: https:/
Submitter: Zuul
Branch: stable/stein
commit b99dee2df6045e5 fe0896acefc5917 98953d375d
Author: Bence Romsics <email address hidden>
Date: Wed Nov 27 17:59:15 2019 +0100
Locate RP-tree parent by hypervisor name
Previously we assumed that we can look up the resource provider (created
by nova) to be used as the parent of the agent and physical NIC resource
provider tree by the name set in the config option DEFAULT.host. This
assumption was wrong.
While nova-compute's DEFAULT.host and neutron-agent's DEFAULT.host
must match for port binding to work, the root resource provider created
by nova does not belong to the compute host (where nova-compute runs)
but it belongs to the compute nodes (i.e. hypervisors). Actually there
may be multiple compute nodes managed by a single nova-compute (think
of ironic). Plus the value of DEFAULT.host and the compute node's ID
may be different even when nova-compute manages a hypervisor on the
same host because of various deployment considerations. For example
when tripleo does not manage the undercloud (so a libvirt hypervisor
returns the plain hostname), but the same tripleo enforces it's host
naming conventions in nova's and neutron's DEFAULT.host settings.
This change enables neutron to use the hypervisor name to locate the
root of the resource provider tree.
We introduce a new configuration option for
(1) ovs-agent: resource_ provider_ hypervisors, for example:
[ovs] br-physnet0, ... provider_ bandwidths = br-physnet0: 10000000: 10000000, ... provider_ hypervisors = br-physnet0: hypervisor0, ...
bridge_mappings = physnet0:
resource_
resource_
(2) sriov-agent: resource_ provider_ hypervisors, for example:
[sriov_nic] provider_ bandwidths = ens5:10000000: 10000000, ... provider_ hypervisors = ens5:hypervisor 1,...
bridge_mappings = physnet1:ens5,...
resource_
resource_
For both agents 'resource_ provider_ hypervisors' values default to gethostname( ) for each key in resource_ provider_ bandwidths.
socket.
We try to not block later developments in which one neutron
agent may manage devices on multiple hosts. That's why we allow
the each physdev to be associated with a different hypervisor.
But here we do not try to solve the problem that the natural physdev
identifiers may not be unique accross multiple hosts. We leave solving
this problem to whoever wants to implement an agent handling devices of
multiple hosts.
(3) We extend report_state message's configurations field alike:
{ mappings' : {'physnet0': 'br-physnet0'}, provider_ bandwidths' : {
'br-physnet0' : {'egress': 10000000, 'ingress': 10000000}}, provider_ hypervisors' : {'br-physnet0': 'hypervisor0'},
'bridge_
'resource_
'resource_
...
}
(4) In neutron-server we use state.configura tions.resource_ provider_ hypervisors. PHYSDEV state.host as before.
report_
when selecting parent resource provider for agent and physdev
RP-tree. When not available in the message we fall back to using
report_
Since we only changed the free-format configurations field of the
report_state message rpc version is not bumped and we expect this
change to be backported to stein and train.
Removed unapplicable TODO notes from backport.
Conflicts: plugins/ ml2/drivers/ mech_sriov/ agent/sriov_ nic_agent. py tests/unit/ plugins/ ml2/drivers/ mech_sriov/ agent/test_ sriov_nic_ agent.py
neutron/
neutron/
Change-Id: I9b08a3a9c20b70 2b745b41d4885fb 5120fd665ce 37badf429a90d5c f57e4c455c) e5495a5b74b7156 bd5a80f03c)
Closes-Bug: #1853840
(cherry picked from commit 258eebea71b1cac
(cherry picked from commit 9a6766470ef127e