This patch adds support for vlan_transparent in the ovn mechanism
driver. So ovn is now second mech_driver after linuxbridge which can be
used with vlan_transparent networks.
It just adds "vlan-passthru" option to the Logical Switch's "other
config".
This needs also changes in the core OVN which are available only in OVN
master branch for now. See [1] for details.
[1] https://patchwork.ozlabs.org/project/ovn/patch/20201110023449.194642-1-ihrachys@redhat.com/
Change-Id: I76b8ba959398dcffff112d26ae7d81ff428be992
In RULES_INGRESS_TABLE table 82 there is a rule for allow established and
related connections. The current rule sends the packet directly to the dest
port without doing a mac learning. This is causing ovs to age out the dest mac
of the remote VM and causing the rule to be changed in flood rule. For the normal
case it fine as they try to avoid high cpu. ovs hardware offload reduce cpu usage
by moving some of the packet processing to nic and flood rule is not offloaded,
therefore it prefre to use the NORMAL action to avoid the flood rule.
We also keep the same logic as today when using explicitly_egress_direct=True
which avoid NORMAL action in the entire pipeline.
Closes-Bug: #1897637
Change-Id: I9b611d62be5d0529e8b35e3d8280baa5be54bc2b
Add file to the reno documentation build to show release notes for
stable/victoria.
Use pbr instruction to increment the minor version number
automatically so that master versions are higher than the versions on
stable/victoria.
Change-Id: I61b2e36ad6e0d7accc2baa19f0e52d2469b996b0
Sem-Ver: feature
Both drivers have different approaches when it comes to the metatada
agent, for one the metadata agent for ML2/OVN runs on the compute nodes
(it's distributed) instead of the controller nodes.
The previous default of "<# of CPUs> / 2" did not make sense for ML2/OVN
and if left unchanged could result in scalation problems because of the
number of connections to the OVSDB Southbound database, as seeing in
this email thread for example [0].
This patch puts a placeholder value (None) on the default field of
the "metadata_workers" config by not setting it immediately and then
conditionally set the default value based on each driver:
* ML2/OVS defaults to <# CPUs> // 2, as before.
* ML2/OVN defaults to 2, as suggested in the bug description and also
what's default in TripleO for the OVN driver.
[0]
http://lists.openstack.org/pipermail/openstack-discuss/2020-September/016960.html
Change-Id: I60d5dfef38dc130b47668604c04299b9d23b59b6
Closes-Bug: #1893656
Signed-off-by: Lucas Alvares Gomes <lucasagomes@gmail.com>
When "uplink-status-propagation" extension is enabled, new ports
created will default the value of "propagate_uplink_status" to True.
Closes-Bug: #1888487
Change-Id: If1e533a61aeebbb4761d669c516fe86a4381765c
In the spec we said:
"""
When the metadata proxy processes a request, it gathers the L2 addresses
of a VM, and the source interface, and passes it to the metadata service.
The Metadata service, instead of using the VM IP, uses the "VM MAC" and
"Gateway MAC" to identify the instance.
"""
But since we switched from the home-grown metadata-ns-proxy to haproxy
we no longer control some of the headers included, like X-Forwarded-For.
haproxy allows us to turn X-Forwarded-For on or off, but it cannot
give us an X-Forwarded-For-MAC header.
Instead it seems we have to rely on the source address being the IPv6
link local address generated from the NIC's MAC address as specified
in RFC 4291:
https://tools.ietf.org/html/rfc4291#section-2.5.6https://tools.ietf.org/html/rfc4291#appendix-A
Note that means you cannot use IPv6 Privacy Extensions:
https://tools.ietf.org/html/rfc4941
Change-Id: Ife592fcfc69e26f61ec1f45c06821cb025cc7cf2
Closes-Bug: #1460177
There is no real reason we should be using some of the
terms we do, they're outdated, and we're behind other
open-source projects in this respect. Let's switch to
using more inclusive terms in all possible places.
Change-Id: I99913107e803384b34cbd5ca588451b1cf64d594
Patch [1] added option "no_track" to the keepalived's config file which
is generated by L3 agent in HA mode.
This was added to handle properly keepalived 2.x and interfaces which
are in DOWN state in the backup nodes.
But this "no_track" option is not compatible with keepalived 1.x series
which is available e.g. on Ubuntu 18.04.
As there is no easy way to check automatically if keepalived supports or
not this config flag, this patch introduces new config option
"keepalived_use_no_track".
If this config option will be set to False, neutron L3 agent will not
add "no_track" to the keepalived's config.
As master branch is moving to gate on Ubuntu 20.04 where keepalived 2.x
is already available, this new config option default value is set to
True.
[1] https://review.opendev.org/#/c/721799/
Change-Id: I2dfdb9f56de28d56ca0f240ff34fa7c3a12e339b
Closes-Bug: #1890400
This is a subset of the changes for implementing the floating IP
port forwarding feature in neutron, using OVN as the backend.
This changeset covers the core implementation for portforwarding/drivers/ovn,
mech_driver, ovn-router as well as a subset of tests.
Port forwarding support in ovn_db_sync is not included here to facilitate review.
That, as well as all other supporting changes, are under the ovn/port_forwarding topic:
https://review.opendev.org/#/q/topic:ovn/port_forwarding+(status:open+OR+status:merged)
Depends-On: https://review.opendev.org/#/c/726478/
Partially-implements: ovn/port_forwarding
Partial-Bug: #1877447
Change-Id: I019fe11ac1ddcf2304f3f144c62d52667fc11dce
This patch adds the support to allow role based access control
on quota of resources.
Change-Id: I6544d4a0794944abb3e1c2ff89134bf313cf35e8
Closes-Bug: #1671448
This resolves a bug that causes stale records to be kept in place when
an admin deletes a port, server or floating IP that was created in some
project other than the admin project.
Change-Id: I7cbb0e87a7e87f23ccf5d8750835b4785693473a
Closes-Bug: #1875981
Now that we use setproctitle for neutron-server workers (and
neutron-keepalived-state-change), this has the side effect of changing
the process name for agents, impacting some monitoring systems. More
details in launchpad bug.
This patch fixes it by setting the name with setproctitle to:
agent name (original process name).
Also use the newly introduced name constants to replace existing
hardcoded uses.
Change-Id: I74c3a4d3e9f833752571a75f196560cd45529385
Closes-Bug: #1881297
This option allows to configure Number of times nova or ironic client
should retry on any failed http call.
Default value for this new option is "3".
Change-Id: I795ee7ca729646be0411a1232bf218015c65010f
Closes-Bug: #1883712
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>
Currently codes only support assocate tunnel network and vlan network
to DVR router. This patch add codes that make the flat network assocate
to DVR router and make it work fine.
The patch also remove two unused constant entries: 'FLAT_VLAN_ID' and
'LOCAL_VLAN_ID'
Change-Id: I7d792ce288d96548298f169748565266a130bd86
Closes-Bug: #1876092
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
When a port is created the dns-assignment (dns-domain part)
was always taken form Neutron config dns_domain which is not
always true, since it could be Neutron network dns_domain or
the dns_domain sent when creating the port
Change-Id: I7f4366ff5a26f73013433bfbfb299fd06294f359
Closes-Bug:1873091
Switch to openstackdocstheme 2.2.1 and reno 3.1.0 versions. Using
these versions will allow especially:
* Linking from HTML to PDF document
* Allow parallel building of documents
* Fix some rendering problems
Update Sphinx version as well.
Set openstackdocs_pdf_link to link to PDF file. Note that
the link to the published document only works on docs.openstack.org
where the PDF file is placed in the top-level html directory. The
site-preview places the PDF in a pdf directory.
Set openstackdocs_auto_name to use 'project' as name.
Change pygments_style to 'native' since old theme version always used
'native' and the theme now respects the setting and using 'sphinx' can
lead to some strange rendering.
Remove docs requirements from lower-constraints, they are not needed
during install or test but only for docs building.
openstackdocstheme renames some variables, so follow the renames
before the next release removes them. A couple of variables are also
not needed anymore, remove them.
See also
http://lists.openstack.org/pipermail/openstack-discuss/2020-May/014971.html
Change-Id: I780eea00c9c47f52dcc7928546fd22dec5d145b4
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
Add file to the reno documentation build to show release notes for
stable/ussuri.
Use pbr instruction to increment the minor version number
automatically so that master versions are higher than the versions on
stable/ussuri.
Change-Id: Ie18c24d8aa1bf0b2508ccdf55994f9425ccf2bd3
Sem-Ver: feature