This patch is ading IGMP snooping support in the OVN driver. Multicast
support has been introduced in core OVN upstream.
Also, the patch always sets the "mcast_flood_unregistered" config in
the OVN Logical_Switch to the same value as the "mcast_snoop" config.
This is so that OVN matches the OVS behavior which is to enable IGMP
flooding by default [0] (in OVN, by default it's false).
[0] http://www.openvswitch.org/support/dist-docs/ovs-vsctl.8.txt (grep
for "mcast-snooping-disable")
Change-Id: I32f61ba3dd06d7eacf76a74c5c44e1286f90e584
Co-Authored-By: Daniel Alvarez <dalvarez@redhat.com>
Signed-off-by: Lucas Alvares Gomes <lucasagomes@gmail.com>
Security group can have a state of empty ports but non-empty members. So
we need skip the flow update only when members dict is empty.
Change-Id: I429edb3d2dea5fa97441909b4d2c776f97f0516f
Closes-Bug: #1862703
Related-Bug: #1854131
Remove this duplicated option and rely only in OVS.integration_bridge.
NOTE: other projects are still using it; first we need to deprecate it
in those projects.
Change-Id: I4e826c8b9fa764b1820adacc3427934dc393c0bc
Related-Bug: #1856152
This change proposes a ML2 plugin extension to implement tagging during
bulk port creation.
Change-Id: Ic70f7d282db478c69016ab1c317c5cae786401ce
Related-Bug: #1815933
Add the `description` field to `PortForwardings`
using the standard attributes like in the
`FloatingIPs`.
Depends-On: https://review.opendev.org/#/c/692580/
Depends-On: https://review.opendev.org/#/c/698662/
Implements: blueprint portforwarding-description
Closes-Bug: #1850818
Change-Id: Ibac91d24da2b82cdce72165d1295fa5d4475ffd3
Signed-off-by: Pedro Martins <phpm13@gmail.com>
I mixed up the bug number and the gerrit change number in a previous
release note.
TrivialChange
Change-Id: I7599be8b7459c44db8e34d0de536154dccb19134
Related-Bug: #1853840
Do not flood the packets to bridge, since we have the
bridge port list, we can add a simple direct flow to
the right port only.
Closes-Bug: #1732067
Related-Bug: #1841622
Change-Id: I14fefe289a19b718b247bf0740ca9bc47f8903f4
As described in [0] a new attribute ``dns_publish_fixed_ip`` is added
to subnets, allowing to specify directly whether DNS records should be
published for this subnet. This overrides the previous behaviour that
makes this decision based on various properties of the network that
the subnet is contained in, see [1].
[0] https://launchpad.net/bugs/1784879
[1] https://docs.openstack.org/neutron/latest/admin/config-dns-int-ext-serv.html
Change-Id: I14605ead2694d9e9422b3d7b519aed2e3c340e2a
Partial-Bug: 1784879
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
there is a spelling error in the document, the 'neutron-server'
was wrongly written as 'neutron-serer'.
Change-Id: I5e6995f46474570289dfb76caaad86a3494a2bbd
Related-Bug: #1854687
In case when user's security group contains rules created e.g.
by admin, and such rules has got admin's tenant as tenant_id,
owner of security group should be able to see those rules.
Some time ago this was addressed for request:
GET /v2.0/security-groups/<sec_group_id>
But it is also required to behave in same way for
GET /v2.0/security-group-rules
So this patch fixes this behaviour for listing of security
group rules.
To achieve that this patch also adds new policy rule:
ADMIN_OWNER_OR_SG_OWNER which is similar to already existing
ADMIN_OWNER_OR_NETWORK_OWNER used e.g. for listing or creating
ports.
Change-Id: I09114712582d2d38d14cf1683b87a8ce3a8e8c3c
Closes-Bug: #1824248
Currently, if dhcp mapping from a network is removed, it is reassigned
to the network. This is because of the Network Scheduler's schedule
function, which considers balancing the networks with the agents, whether
enable_dhcp is set on its subnets or not. It does not take into account
the network_auto_schedule config option. This is particularly disturbing
when considering backends which have their provide their own DHCP.
With this patch, if network_auto_schedule is set to False, networks wont
be automatically scheduled to DHCP Agents. If DHCP is to be mapped to a
network, it can be mapped using the CLI itself.
While it may seem that this change is breaking what is already working,
but as mentioned earlier, if there are network backends which provide DHCP
support themselves, they wont need the automatic mapping, which the term
"network_auto_schedule" actually stands for.
Closes-Bug: #1647421
Change-Id: If1a6a2a174d0f737415efa2abce518722316a77b
This reverts commits:
9a022e7d7b85b7c21cf26698fe59c818c4577194
d7604169988726d121cdc9727accfeb6e29f4aed
As the issue is relevant only for old kernels and almost 4 years
have passed since this fix was introduced, it is safe to undo the
workaround to use ip link show command for determining whether or not
a VF is assigned with macvtap(and followup patch that fixed excessive
use of ip link show commans).
reverting this commit will benefit the agent by reducing the amount of
ip link calls.
While it is possible to perform a revert-per-commit, this change should
really go in as one commit for clarity and avoid introducing a
performance degradation in case one is merged without the other.
Conflicts:
neutron/plugins/ml2/drivers/mech_sriov/agent/eswitch_manager.py
neutron/plugins/ml2/drivers/mech_sriov/agent/pci_lib.py
neutron/tests/unit/plugins/ml2/drivers/mech_sriov/agent/test_eswitch_manager.py
neutron/tests/unit/plugins/ml2/drivers/mech_sriov/agent/test_pci_lib.py
Conflicts details:
In eswitch_manager: merge tool was unable to properly revert
is_assigned_vf() due to changes in later patches.
In pci_lib: conflicts with later changes to is_macvtap_assigned()
and link_show() that are no longer required and revert
of IPCommandDeviceError definition.
In unit tests: conflicts due to newly added tests and reverting the
IPCommandDeviceError exception definition.
Sorting out mocks as link_show() method was removed
Related-bug: #1523083
Change-Id: I04ea8eb63de07a6e1e51c2790c5920b086b8542c
Instead of restarting the dnsmasq agent for every IP we do this
in bulk. That is, if a network has N updates in X seconds then we will
restart the process once with the ports configured in the X seconds and
not N Times.
A new configuration variable have been added:
- bulk_reload_interval - time to wait between bulk reloads. This is 0 by
default to ensure backwards compatibility. If the value is not 0 the
new functionlay is invoked.
Change-Id: Ieff5ce4506fd4e7fa427eb50c50fbe316f67103f
Neutron-ovs-agent can now enable IGMP snooping in integration bridge
if config option "igmp_snooping_enable" in OVS section in config will
be set to True.
It will also set mcast-snooping-disable-flood-unregistered=true
so flooding of multicast packets to all unregistered ports will be
disabled also.
Both changes are applied on integration bridge.
Change-Id: I12f4030a35d10d1715d3b4bfb3ed5efb9aa28f2b
Closes-Bug: #1840136
This config option was added by [1] and deprecated to
be removed in Mitaka cycle. As we are now in Ussuri, it's
time to finally get rid of it.
[1] https://review.opendev.org/#/c/197210/
Change-Id: Ibd16a0587c88e2dbee1b7938e52140f68821eec6
A security group rule where port_range_min:port_range_max
is 1:65535 is specifying all ports, but it is not optimal
for backends to try and implement this potentially large
rule.
Since it is essentially the entire port range, change
min:max to be None, making the rule specify the entire
protocol instead.
Change-Id: Iff22e2fc84d679e20a5a04b8516750c6ea949078
Closes-bug: #1848213
This patch sets the MTU attribute to non-nullable, the code
that get the MTU and update the network in some methods can
be removed. If the MTU is empty before the pike version, it
is set to the default value of 1500.
Change-Id: Id4d738dde7fa4b7caccabad0aac542b82b4d7af1
Closes-Bug: #1842261
Since it's no longer supported past Train, lets stop
running the tests.
Updated docs and made some pep8 code tweaks as well.
Change-Id: I1c171ab906a3b4c66558163ad26947ebf710a276
In some deployments, the "neutron" user does not have the permissions
to modify the kernel interfaces. In those cases the radvd user should
be defined. This patch introduces a new config option: "radvd_user".
This config option is the username passed to radvd, used to drop root
privileges and change user ID to username and group ID to the primary
group of username. If no user specified (by default is an empty string),
the user executing the L3 agent will be passed. If "root" specified,
because radvd is spawned as root, no "username" parameter will be
passed.
Change-Id: Ie9a6fbf04d453a3c1c0bddf9ecaa3d4d6467e8ff
Closes-Bug: #1844688
Add file to the reno documentation build to show release notes for
stable/train.
Use pbr instruction to increment the minor version number
automatically so that master versions are higher than the versions on
stable/train.
Change-Id: Id476cf89f4f8f0ab41529d44510a7ed0572c63c5
Sem-Ver: feature
This fix removes the case sensitivity when performing
port list by mac address criteria.
Closes-Bug: #1843428
Change-Id: I7ab6934ea333467d2efc5da0471b1af82ebb44b8
The prelude section is usually used for release highlights.
As of now, the prelude section has only one contents on SmartNIC
support, but it is not necessarily most important topic.
It is already covered by "features" section, so it looks natural
to drop it from the prelude section.
Change-Id: Ibfe773f93ee5d805dcad27938209275197dadadb