neutron/releasenotes/notes/locate-rp-tree-parent-by-hypervisor-name-3244ed87dc57f950.yaml

24 lines
1.2 KiB
YAML
Raw Normal View History

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] bridge_mappings = physnet0:br-physnet0,... resource_provider_bandwidths = br-physnet0:10000000:10000000,... resource_provider_hypervisors = br-physnet0:hypervisor0,... (2) sriov-agent: resource_provider_hypervisors, for example: [sriov_nic] bridge_mappings = physnet1:ens5,... resource_provider_bandwidths = ens5:10000000:10000000,... resource_provider_hypervisors = ens5:hypervisor1,... 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: { 'bridge_mappings': {'physnet0': 'br-physnet0'}, 'resource_provider_bandwidths': { 'br-physnet0': {'egress': 10000000, 'ingress': 10000000}}, 'resource_provider_hypervisors': {'br-physnet0': 'hypervisor0'}, ... } (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. Change-Id: I9b08a3a9c20b702b745b41d4885fb5120fd665ce Closes-Bug: #1853840
2019-11-27 17:59:15 +01:00
---
fixes:
- |
Neutron now locates the root resource provider of the resource provider
tree it creates by using the hypervisor name instead of the hostname.
These are different in rare cases only. The hypervisor name can be set
per physical network device in config option
``resource_provider_hypervisors`` which is located in the ``[ovs]``
ini-section for ``ovs-agent`` and ``[sriov_nic]`` ini-section for
``sriov-agent``. Hypervisor names default to ``socket.gethostname()``
which works out of the box with ``libvirt`` even when the ``DEFAULT.host``
config option is set to a non-default value. We believe this change fixes
`bug 1853840 <https://launchpad.net/bugs/1853840>`_.
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] bridge_mappings = physnet0:br-physnet0,... resource_provider_bandwidths = br-physnet0:10000000:10000000,... resource_provider_hypervisors = br-physnet0:hypervisor0,... (2) sriov-agent: resource_provider_hypervisors, for example: [sriov_nic] bridge_mappings = physnet1:ens5,... resource_provider_bandwidths = ens5:10000000:10000000,... resource_provider_hypervisors = ens5:hypervisor1,... 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: { 'bridge_mappings': {'physnet0': 'br-physnet0'}, 'resource_provider_bandwidths': { 'br-physnet0': {'egress': 10000000, 'ingress': 10000000}}, 'resource_provider_hypervisors': {'br-physnet0': 'hypervisor0'}, ... } (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. Change-Id: I9b08a3a9c20b702b745b41d4885fb5120fd665ce Closes-Bug: #1853840
2019-11-27 17:59:15 +01:00
upgrade:
- |
For users affected by `bug 1853840
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] bridge_mappings = physnet0:br-physnet0,... resource_provider_bandwidths = br-physnet0:10000000:10000000,... resource_provider_hypervisors = br-physnet0:hypervisor0,... (2) sriov-agent: resource_provider_hypervisors, for example: [sriov_nic] bridge_mappings = physnet1:ens5,... resource_provider_bandwidths = ens5:10000000:10000000,... resource_provider_hypervisors = ens5:hypervisor1,... 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: { 'bridge_mappings': {'physnet0': 'br-physnet0'}, 'resource_provider_bandwidths': { 'br-physnet0': {'egress': 10000000, 'ingress': 10000000}}, 'resource_provider_hypervisors': {'br-physnet0': 'hypervisor0'}, ... } (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. Change-Id: I9b08a3a9c20b702b745b41d4885fb5120fd665ce Closes-Bug: #1853840
2019-11-27 17:59:15 +01:00
<https://launchpad.net/bugs/1853840>`_ the hypervisor name
now can be set per physical network device in config option
``resource_provider_hypervisors`` which is located in the ``[ovs]``
ini-section for ``ovs-agent`` and ``[sriov_nic]`` ini-section for
``sriov-agent``. Hypervisor names default to ``socket.gethostname()``
which works out of the box with ``libvirt`` even when the
``DEFAULT.host`` config option is set to a non-default value.