In this change, we add the ability to create high availability
user defined router flavors under the ML2/OVN L3 service
plugin.
Closes-Bug: #2020823
Change-Id: I0d26f672d6239d840d3cf817a2553a06ef00a854
This artifact is no longer used in the "Logical_Router" registers (in
the "options" field) to mark this "Logical_Router" as unhosted. A
"Logical_Router" is considered as unhosted if the gateway
"Logical_Router_Ports" have no "chassis" set.
This artifact is also used to create a "Gateway_Chassis" register
pointing to a inexisting invalid chassis called
"neutron-ovn-invalid-chassis". Any "Logical_Router_Port" not bound
to a chassis will have no value in "gateway_chassis" (NOTE1).
NOTE1: this is valid now with the current two OVN L3 schedulers that
use "gateway_chassis" to schedule the "Logical_Router_Port" of a
router. In a future, we can consider using "ha_chassis_group" for
scheduling.
Partial-Bug: #2052821
Related-Bug: #2019217
Change-Id: I12717936fe2bc188545309bacb8a260981f14c88
Document the ``OVNGatewayLeastLoadedScheduler`` behavior when
there are multiple gateway ports.
Partial-Bug: #2002687
Change-Id: I99cf269e35619a2e1fb680d8decbc613267ca62e
Signed-off-by: Frode Nordahl <frode.nordahl@canonical.com>
Currently at least 1 rpc worker is launched even when a user requests
zero workers by setting rpc_workers=0. The setting of rpc_workers=0 is
used when ml2-ovn plugin is used without any additional agent, and in
this deployment pattern the single rpc worker is not at all used.
This change ensures no rpc worker is launched when rpc_workers options
is explicitly set to 0. This may be classified as a breaking change,
but is consistent with the earlier change[1] for rpc_workers=0.
[1] 3e1e2d63b3
Closes-Bug: #2052484
Change-Id: I878e50c3192ecd3b145ded0ab8394845a089696e
This new section describes how the OVN L3 schedulers distribute
the ``Chassis`` candidate list among the Available Zones, in
order to provide more resilience to the L3 HA: if the active
LRP binding fails, the next in the list will belong to another
AZ.
Related-Bug: #2030741
Change-Id: I20aaeefb33c424dc1a9c13f94f2912d0fa973166
This new document adds:
* A definition of the OVN L3 scheduler
* A description of the different OVN L3 schedulers
* How the LRP are re-scheduled if the gateway chassis list
changes.
Related-Bug: #2023993
Change-Id: Idcc0e34227e47df53a1f395c8fd163723d54b933
Update l3 ovn schedulers (chance, leastloaded) to ensure that LRP gateways are distributed over chassis in the different eligible AZs.
Previous version already ensure that LRP gateways were scheduled over chassis in eligible AZs. But, depending on the deployment characteristics, all these chassis could be in the same AZ. In some use-cases, it could be needed to have LRP gateways in different AZs to be resilient on failures.
This patch re-order the list of eligible chassis to add a priority on selecting chassis in different AZs.
This should provide a solution for users who need to have their router gateways scheduled on chassis from different AZs.
Closes-Bug: #2030741
Change-Id: I72973abbb8b0f9cc5848fd3b4f6463c38c6595f8
Support is added to the OVN L3 service plugin for the router
flavors and service type framework
Partial-Bug: #2020823
Change-Id: If40d7b39e7b59a39ff7622bd823dbdb14bfc69d2
Do not allow the subnet cidr of :: to be used when
creating a subnet, except in the case IPv6 prefix
delegation has been specified in the request.
Closes-bug: #2028159
Change-Id: I480e9a117513996f3c070acd4ba39c2b9fe9c0f1
Prior to this patch, ML2/OVS and ML2/OVN had inconsistent IGMP
configurations. Neutron only exposed one configuration option for IGMP:
igmp_snooping_enabled.
Other features such as IGMP flood, IGMP flood reports and IGMP flood
unregistered were hardcoded differently on each driver (see LP#2044272
for a more details).
These hardcoded values has led to many changes over the years tweaking
them to work on different scenarios but they were never final because
the fix for one case would break the other.
This patch introduces 3 new configuration options for these other IGMP
features that can be enabled or disabled on both backends. Operators
can now fine tune their deployments in the way that will work for them.
As a consequence of the hardcoded values for each driver we had to break
some defaults and, in the case of ML2/OVS, if operators want to keep
things as they were before this patch they will need to enable the new
mcast_flood and mcast_flood_unregistered configuration options.
That said, the for ML2/OVS there was also an inconsistency with the help
string of igmp_snooping_enabled configuration option as it mentioned
that enabling snooping would disable flooding to unregistered ports but
that was not true anymore after the fix [0].
[0] https://bugs.launchpad.net/neutron/+bug/1884723
Closes-Bug: #2044272
Change-Id: Ic4dde46aa0ea2b03362329c87341c83b24d32176
Signed-off-by: Lucas Alvares Gomes <lucasagomes@gmail.com>
This patch is part of the solution for LP #2037294 and updates the
documentation to explain the new "enable-chassis-as-extport-host"
configuration as well as enhancing the documentation in general
to better explain each configuration, database information and
high availability for external ports.
Change-Id: Iad048a71653dc791fc27585b509c02470e5d08a2
Related-Bug: #2037294
Signed-off-by: Lucas Alvares Gomes <lucasagomes@gmail.com>
Nova will automatically translate VF capabilities to Neutron
port binding profiles after patch [1] will be merged. Existing
recommendations in "admin/config-ovs-offload.html" should be
updated: there is no need to define capabilities in port
binding profiles for new ports anymore.
[1] https://review.opendev.org/c/openstack/nova/+/884439
Related-bug: #2020813
Depends-on: https://review.opendev.org/c/openstack/nova/+/884439
Change-Id: I63b0641f6b7ef0e1190f421a90619bb2971d0d44
Over time docs were added or updated such that they were
no longer in alphabetical order based on the index order
or their title strings. Tried to fix it up a bit along
with some capitalization.
Trivialfix
Change-Id: I948b2a1c86faaffed07adcf0198a3fba72401abe
This patch updates docs related to the Security Groups to add info about
possibility to change default set of rules created in every new security
group.
It also adds release note about this new API in Neutron.
Closes-Bug: #1983053
Change-Id: I0f6ecc5cf374a0090930e9786834ed7a1be3dc0b
Just describe what a firewall does, not its implemenation
details. This text was copied from elsewhere and mentioning
iptables is outdated and not correct.
Change-Id: Ia078fe6f3cee873d37a4621c98a089a90cd47d51
Closes-bug: #2030753
Neutron-metadata-agent can cause big load on the RPC bus and
neutron-server by asking for port details very often. And this can be
optimized by simple using cache mechanism provided by oslo.cache module.
This feature wasn't really described in our docs so this patch adds
short document about why and when use cache in metadata agent, why it's
not needed in the neutron-ovn-metadata-agent and how to enable it.
Closes-Bug: #2024581
Change-Id: I2c7e496f4c0588eebc1fbf42a43473101f67032f
This patch makes conditional the existing DB migration that adds
the new indexes "target_tenant" and "action" in the "*rbacs" tables.
The rationale of this patch is to be able to manually improve older
systems by just manually creating the indexes in the database.
Once these indexes are added, those operations including RBACs
checks (all these called from non-admin user to RBAC administrated
resourced) will be improved.
This patch is avoiding the migration issue a system could find if
these indexes have been manually added and then the system is
upgraded. The new check added will first retrieve the table indexes;
if the index is already present, the index addition is skipped.
Closes-Bug: #2020802
Change-Id: I1962fbc844bb67180e9071bcee01f8e95853bdda
When we use the ovn driver, the security group is implemented
by the ACL of ovn. There is no need to send rpc messages.
Closes-Bug: #2007327
Change-Id: I4b486c910ed298633ac6f60fd93f695c6c3bfef2
Requests handled by the metadata-agents can now be rate-limited by
source-ip. This is done to protect the OpenStack control plane against
VMs querying the metadata endpoint in an overly enthusiastic way.
Co-authored-by: Miguel Lavalle <mlavalle@redhat.com>
Related-Bug: #1989199
Change-Id: I748ccfa8b50496dcbcbe41fd22f84249a4d46b11
We had a number of code blocks that were being incorrectly rendered
inside block quotes, which messed with formatting somewhat. Correct
them. This was done using the following script:
sphinx-build -W -b xml doc/source doc/build/xml
files=$(find doc/build/xml -name '*.xml' -print)
for file in $files; do
if xmllint -xpath "//block_quote/literal_block" "$file" &>/dev/null; then
echo "$file"
fi
done
Note that this also highlighted a file using DOS line endings. This is
corrected.
Change-Id: If63f31bf13c76a185e2c6eebc9b85f9a1f3bbde8
Signed-off-by: Stephen Finucane <sfinucan@redhat.com>
A network's MTU is now only valid if it is the minimum value
allowed based on the IP version of the associated subnets,
68 for IPv4 and 1280 for IPv6.
This minimum is now enforced in the following ways:
1) When a subnet is associated with a network, validate
the MTU is large enough for the IP version. Not only
would the subnet be unusable if it was allowed, but the
Linux kernel can fail adding addresses and configuring
network settings like the MTU.
2) When a network MTU is changed, validate the MTU is large
enough for any currently associated subnets. Allowing a
smaller MTU would render any existing subnets unusable.
Closes-bug: #1988069
Change-Id: Ia4017a8737f9a7c63945df546c8a7243b2673ceb
This patch documents how to detect that the system has duplicated
"Chassis" and "Chassis_Private" registers or when a "Chassis_Private"
register is orphaned, and how to proceed to health the OVN Southbound
database.
Closes-Bug: #2012104
Change-Id: I926e6b9fe5fbad2968fc92e65082b7bb0d8571a9
IPv4 DAD is non-existent in Linux or its failure is silent, so we
never needed to catch and ignore it. On the other hand IPv6 DAD
failure is explicit, hence comes this change.
This of course leaves the metadata service dead on hosts where
duplicate address detection failed. But if we catch the
DADFailed exception and delete the address, at least other
functions of the dhcp-agent should not be affected.
With this the IPv6 isolated metadata service is not redundant, which
is the best we can do without a redesign.
Also document the promised service level of isolated metadata.
Added additional tests for the metadata driver as well.
Change-Id: I6b544c5528cb22e5e8846fc47dfb8b05f70f975c
Partial-Bug: #1953165
The quota guide was using the old 'neutron quota-list' style
commands, update to use the 'openstack quota' ones. Removed
wording on adding L2/L3 ones as they are all in neutron.conf.
Trivialfix
Change-Id: I1cb19ff93e617d19338b0ddfd7eb496eb1ae3572
The current document states that O flag will be 1 when ipv6_ra_mode is
dhcpv6_stateful, but the actual implementations of both ml2/OVS and
ml2/OVN set O flag to 0 according to the following implementations:
ML2/OVS
f545c002dc/neutron/agent/linux/ra.py (L53-L55)
ML2/OVN
a5238e6234/controller/pinctrl.c (L3733-L3734)a5238e6234/lib/actions.c (L3349-L3350)
This actual behavior looks correct because O flag can be either 1 or 0
when M flag is 1, according to the following statement of RFC 4861:
https://www.rfc-editor.org/rfc/rfc4861#section-4.2
If the M flag is set, the O flag is redundant and can be ignored
because DHCPv6 will return all available configuration information.
To make consistency between the documet and actually behavior, this
commit changes the document to state that O flag can be either 1 or 0
when ipv6_ra_mode is dhcpv6_stateful.
Closes-Bug: #2011687
Change-Id: Id61031d7e707d0ba7b007bae0c9e0f59b8b40f8b
This patch is a partial revert of [1], reinstantiating the code merged
in [2]. This patch is the complementary to [1]: the traffic with
custom ethertypes is allowed in the ingress processing tables, same
as [1] is allowing all traffic from the virtual machine ports in this
host to leave the node. Both, this patch and [1], are bypassing the
OVS firewall just for the traffic with the configured allowed
ethertypes and just for/to the local ports and MAC addresses.
Any other traffic not coming from a local port or with destination
a local port, will be blocked as is now.
[1]https://review.opendev.org/c/openstack/neutron/+/678021
[2]https://review.opendev.org/c/openstack/neutron/+/668224/
Closes-Bug: #2009221
Related-Bug: #1832758
Change-Id: Ib8340d9430b946a446edf80886c49fbac729073c
Since Antelope is a code name, add the release name as
well, similar to qos-min-bw doc.
Trivialfix
Change-Id: I31b03178c888990002340b83083a17a5f1ccc94a
The OVS firewall driver requires nf_conntrack module(s)
to be loaded to function properly. While they are typically
loaded automatically, add a note to the admin guide about
the requirement to make it explicit.
Closes-bug: #1834213
Change-Id: I55871eff1e37d4155b8d2b5ae8c182d160c4af9f
There was not an example of how to delete an auto
allocated topology (get me a network), so add one.
Only a partial fix as it seems the api-ref doc in
neutron-lib is incorrect as there is only create and
delete operations on this resource, not show.
Change-Id: Iaa797b7e0c1c9bac25ff00659a74286173297206
Partial-bug: #1617548
Add "broken pipe" example error message to WSGI guide in
rpc_workers section, could help diagnose agent issues.
Trivialfix
Change-Id: I6e95614bce42124f125be4c23fff0d923ea9ebcc
Closes-bug: #1855919