This patch is adding support for the router_availability_zone extension
for Neutron.
The OVN driver will now read from the router's availability_zone_hints
field and schedule the router ports onto OVN chassis belonging to those
AZs.
Since the OVN driver does not rely on the L3 agent, this patch does not
re-use the configuration option for the agent to configure the
availability zone that a Chassis belongs to (even because there's no
configuration file in nodes such as networker nodes). Instead, this
patch reuses the "ovn-cms-options" field from the local OVSDB to
configure the Chassis. The follow syntax has been used:
$ ovs-vsctl set Open_VSwitch .
external-ids:ovn-cms-options="enable-chassis-as-gw,availability-zones=az0:az1"
In the example above, the Chassis has been configured to belong to two
AZs: "az0" and "az1".
This patch also implements listing the availability zones:
$ openstack availability zone list
As well as validating the router's availability zone hints:
$ openstack router create --availability-zone-hint az0
--availability-zone-hint az1 test_router
The above command would fail if there's no "az0" and "az1" configured in
any OVN chassis.
Documentation for this feature is being written and will be submitted
in a separated patch.
Partial-Bug: #1881095
Change-Id: I4567f3d541d382b6432c1ab3d35276d81ce71d82
Signed-off-by: Lucas Alvares Gomes <lucasagomes@gmail.com>
Limit "ml2_vlan_allocations.vlan_id" values stored in the DB by
adding a check constraint in the DB engine. This check will
verify that vlan_id is in the interval [1, 4094].
Change-Id: Ie6453cb7a2ef0c43baf540c49a03079f4c8d3818
Closes-Bug: #1870400
In the patch [1] we changed definition of the abstract method
"plug" in the LinuxInterfaceDriver class.
That broke e.g. 3rd-party drivers which still don't accept this
new parameter called "link_up" in the plug_new method.
So this patch fixes this to make such legacy drivers to be still working
with the new base interface driver class.
This commit also marks such definition of the plug_new method as
deprecated. Possibility of using it without accepting link_up parameter
will be removed in the "W" release of the OpenStack.
[1] https://review.opendev.org/#/c/707406/
Change-Id: Icd555987a1a57ca0b31fa7e4e830583d6c69c861
Closes-Bug: #1879307
Back in Newton, patch [1] added to the agents possibility to report in
the heartbeat messages if hybrid plug of the ports is required or not.
Usage of "firewall_driver" option by mechanism drivers (so on the
server's side) was kept just for backward compatibility.
But as we are now about 4 years from the [1] I think it should be safe
to do small cleaning, remove usage of this option in the neutron server
and not confuse users where this config option has to be set and why.
[1] https://review.opendev.org/#/c/311814/
Change-Id: I2ccc4c8784c64858acaa3c3431cf9a3d13e5e154
In dnsmasq 2.81 there is a regression (see [1] for details).
Prior versions of dnsmasq would select a host record where:
a) no address is present in the host record.
b) an address matching address family of the client request
is present in the host record.
dnsmasq 2.81 will also use a host record where a only an address
not matching the address family of the client request is present.
The same issue is also backported to the dnsmasq-2.79-11.el8.x86_64
which is e.g. in RHEL 8.2 and Centos 8.
dnsmasq version 2.81 also adds support for using tag's on host
records. When a dhcpv6 request is received, dnsmasq automatically
sets the tag 'dhcpv6'.
This change adds a runtime check, testing for dnsmasq host entry
tag support. And adds 'tag:dhcpv6' to all IPv6 host records when
dnsmasq supports this.
Adding the tag makes dnsmasq prefer the tagged host for dhcpv6
requests, i.e it's a workaround fix for the regression issue.
[1] http://lists.thekelleys.org.uk/pipermail/dnsmasq-discuss/2020q2/014051.html
Closes-Bug: #1876094
Change-Id: Ie654c84137914226bdc3e31e16219345c2efaac9
This patch is adding support for a new port type called "external" in
core OVN.
Prior to this work, when a VM had a SR-IOV port attached to it, OVN itself
wasn't able to reply to things such as DHCP requests packets since the
OVS port was skipped. Core OVN then introduced the concept of "external"
ports which are ports deployed on a different node than the one that the
VM is running and is able to reply to such requests on behalf of the VM.
With this patch, when a port with the VNIC type "direct" and no
"switchdev" capability is created, ovn driver will then create a
logical port with the type "external" for it and add it to a default
HA Chassis Group. The port will then get bound to the "master" (higher
priority) chassis of that group.
Please note that, as a first step, this patch is creating only one HA
Chassis Group which *all* external ports will belong to. That means that
all external ports will be *scheduled onto the same node* (but it's
HA nevertheless). In the future we should enhance this behavior.
Change-Id: Ic6c4bb6c584682169f3ebd73105a847b05dddc76
Closes-Bug: #1841154
Signed-off-by: Lucas Alvares Gomes <lucasagomes@gmail.com>
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>
Adds a new bool option dnsmasq_enable_addr6_list, when
enabled configuration for dnsmasq will be created with a
single dhcp-host entry specifying a list of ip addresses
allocated for a port.
Previously the dnsmasq dhcp-agent driver would write a
separate dhcp-host entry for each fixed-ip of a port in
the dnsmasq hosts file. The result of the previous
behaviour is that dnsmasq will only use one of the config
entries, i.e the first one matching the mac identifier.
The trade-off is that only a single dns_assignment will
be used for IPv6 addresses within the same subnet. (But
in practice, this was always the case since only the
first config entry would be used by dnsmasq.)
Why is this neccecary:
This is done to enable ironic provisioning over IPv6
using DHCPv6-stateful. For background info, please
read dnsmasq-discuss thread:
http://lists.thekelleys.org.uk/pipermail/dnsmasq-discuss/2020q1/thread.html#13671
Closes-Bug: #1861032
Change-Id: I833840e7daed2efa7efaece27cfd1ba28e0feb90
If a user specifies a header in their request for metadata,
it could override what the proxy would have inserted on their
behalf. Make sure to remove any headers we don't want, and
override something that might be present in the request.
If the agent somehow gets a request with both headers it will
silently drop it.
Change-Id: Id6c103b7bcebe441c27c6049d349d84ba7fd15a6
Closes-bug: #1865036
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