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
When ``enable_default_route_bfd`` is set, maintain BFD records
along with default route records. Default route records will
also be fitted with the `output_port` key, which is a requirement
for the OVN BFD support.
Partial-Bug: #2002687
Signed-off-by: Frode Nordahl <frode.nordahl@canonical.com>
Change-Id: I34e2453ab206c13c3ca40c4181970c320bdd8e67
If a router is created and a GW port is subsequently added by
updating the router, the change is not always propagated to the
OVN DB.
This patch fixes this and also adds a functional test case.
Trivial-Fix
Partial-Bug: #2002687
Signed-off-by: Frode Nordahl <frode.nordahl@canonical.com>
Change-Id: I9455678d73fb35b77eac7416917200a419abfa84
The current DeleteLRouterExtGwCommand stops iterating over static
routes once the first route with a ovn_const.OVN_ROUTER_IS_EXT_GW
external_id is found.
There can be multiple static routes with this external ID, so
this patch continues iteration until all external routes are
removed and adds a unit test for this condition.
Trivial-Fix
Partial-Bug: #2002687
Change-Id: Ie43abd8bf511e12a0f64c10bafeaafc0823a2076
Signed-off-by: Frode Nordahl <frode.nordahl@canonical.com>
Without this change pylint fails with:
neutron/objects/trunk.py:75:15: W0143: Comparing against a callable, did you omit the parenthesis? (comparison-with-callable)
Trivial-Fix
Signed-off-by: Frode Nordahl <frode.nordahl@canonical.com>
Change-Id: I97f1dde896be114b81732ff74ab86a4a5be250e4
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>
Map 'ipip' to use the string 'ipencap' so the
IptablesFirewallDriver class in neutron works correctly.
Once neutron-lib is bumped this can be removed.
Add tests for IP protocol 'ipip', '4' and '94' to make
sure the IptablesFirewallDriver class in neutron treats
them correctly.
Long description below.
This is one of those confusing edge cases and I think
Linux is conspiring against us. Let me explain.
1) neutron-lib does correctly define the protocol name 'ipip' as 4.
2) The linux kernel uses the same in in.h:
IPPROTO_IPIP = 4
IPPROTO_BEETPH = 94 (?)
3) iptables maps 'ipip' to 94 and 'ipencap' to 4.
# for num in {0..255}; do iptables -A INPUT -p $num; done
# iptables-save | grep -E 'ipip|ipencap'
-A INPUT -p ipencap
-A INPUT -p ipip
4) /etc/protocols does the same as iptables:
grep -E 'ipencap|ipip' /etc/protocols
ipencap 4 IP-ENCAP # IP encapsulated in IP (officially ``IP'')
ipip 94 IPIP # IP-within-IP Encapsulation Protocol
5) getprotoby{name|number} does what /etc/protocols does:
$ getprotobyname ipip
struct protoent: (0x7fbbbcca9c60)
p_name ipip
p_aliases IPIP
p_proto 94
$ getprotobynumber 4
struct protoent: (0x7fc51ad86be0)
p_name ipencap
p_aliases IP-ENCAP
p_proto 4
Neutron actually builds a mapping based on the getprotoby*
calls, so in the iptables case it winds-up doing the wrong
thing.
Partial-bug: #2054324
Change-Id: Icc84b54be07d39059723d6c233c03aa130102423
Move scheduling logic from OVNClient._create_lrouter_port to an
ovsdbapp command so that scheduling decisions are made on up to
date information as the transaction applies.
One of the main use cases for routers with multiple gateway
ports are resiliency. Whenever there are multiple LRPs present in
a LR, we want to ensure diverse placement of the ports to
minimize impact of chassis failure.
Partial-Bug: #2002687
Signed-off-by: Frode Nordahl <frode.nordahl@canonical.com>
Change-Id: I36860b739a8cb99ba0e7fc65950ea252ad6803c4
This will be used in the next patch set to implement anti-affinity
scheduling for routers with multiple LRPs.
Partial-Bug: #2002687
Signed-off-by: Frode Nordahl <frode.nordahl@canonical.com>
Change-Id: Iff958195f229f7e0714f1285bb3d53497aeec9aa
At present, whenever multiple additions/updates are made to LRPs
with gateway_chassis, each update is put in separate transactions
in an attempt to ensure the scheduler operates on updated
information for each iteration.
This is problematic because we don't have the luxury of creating
separate transactions for updates in all parts of the code base,
and it is also not very efficient.
The OVSDBapp library wraps the OVS Python IDL and provides
different semantics. Most notably the OVSDBapp represents a
Transaction as a list of command objects with `run_idl` methods
for execution at some point in the future. The main loop and the
command objects are not aware of changes made in the current
transaction until it is committed.
Fortunately, as an ovsdbapp transaction is committed, the
underlying OVS Python IDL is kept up to date during the course of
the transaction [0][1][2].
Move implementation of scheduling of unhosted gateways into an
ovsdbapp command, using a plugin reference to the Neutron
OVNClient class for any calls into the Neutron code, allowing
scheduling decisions to be made on up to date data as the
transaction is applied.
0: https://github.com/openvswitch/ovs/blob/e3ba0be48ca4/python/ovs/db/idl.py#L1316
1: https://github.com/openvswitch/ovs/blob/e3ba0be48ca4/python/ovs/db/idl.py#L1400
2: https://github.com/openvswitch/ovs/blob/e3ba0be48ca4/python/ovs/db/idl.py#L2083
Partial-Bug: #2002687
Co-Authored-By: Terry Wilson <twilson@redhat.com>
Co-Authored-By: Brian Haley <haleyb.dev@gmail.com>
Signed-off-by: Frode Nordahl <frode.nordahl@canonical.com>
Change-Id: I83bcf7fe838c0d6b0617c43439643e8443b2bdae
The ML2 and OVN metadata agents have almost identical
code, as the former was copied to the latter and modified.
Instead, combine all the common parts and just have
each do any driver-specific operations separately.
Change-Id: Iff8bc8de16a8afc7c0195bf301d1b0643e17d7c6
The VETH pair between the metadata namespace and the local OVS now
has the same MTU as the network associated to this metadata service.
The "LSP.external_ids" field has a new key defined: "neutron:mtu".
This is the value of the network MTU.
This patch does not update the previous metadata datapaths nor the
existing LSP. This change will affect only to new created ports
and the corresponding metadata datapaths.
Closes-Bug: #2053274
Change-Id: I7ff300e9634e5e3fc68d70540392109fd8b9babc
Since [1], any "Logical_Router_Port" has a key in "external_ids" to
identify if it is an external gateway or not. This key is
"neutron:is_ext_gw". This patch makes use of this key to identify
them in the ``get_lrouter_gw_ports`` method.
This implementation will be useful when the "Logical_Router_Port"
would be bound to an external tunnelled networks. These ports won't
be bound to a "Gateway_Chassis" and the previous logic in this
method will fail.
[1]https://review.opendev.org/c/openstack/neutron/+/907402
Partial-Bug: #2052821
Change-Id: Ieac603b0c7a940693a12170b453eea39dd0eaa47
Check the event ``WaitForCreatePortBindingEvent`` wait method has
finished without a timeout.
Trivial-Fix
Change-Id: Ia7eeb88d148435ec95d16637d7bcea57a999e818
In [1], the available port NUMA policies constant is updated with a
new one. Because this new policy, included in a new extension, has
not been yet added to Neutron, it is needed to specify what policies
are valid and tested in Neutron.
Related-Bug: #2052786
[1]https://review.opendev.org/c/openstack/neutron-lib/+/903531
Change-Id: I5366864d0acc479aa111456e5bf0c57bb963c528
The OVN Northbound ``create_lrouter`` and ``delete_lrouter`` local
implementations have their counterparts in ovsdbapp library, in the
methods ``lr_add`` and ``lr_del``.
Trivial-Fix
Change-Id: I57d0847a5f1ed8881c80fcf0ab022d768656ee2f
In both neutron-metadata and neutron-ovn-metadata agents we should
ensure that haproxy service spawned for network/router is actually
active before moving on.
This patch adds that check and this is similar to what was already
implemented some time ago for the dnsmasq process spawned by the dhcp
agent.
Related-Bug: #2052787
Change-Id: Ic58640d89952fa03bd1059608ee6c9072fbaabf5
The input parameter "is_ovs_port" is no longer needed in the method
``IpLinkCommand.set_netns`` since [1].
[1]https://review.opendev.org/c/openstack/neutron/+/905836
Trivial-Fix
Change-Id: I0e36cf8afe76904997e14eca415a0e978f05c55a
After some interface operations (in particular the
``IpLinkCommand.set_ns`` operation), the network interface is
temporarily not present in the destination namespace. This patch
retries the interface "ip link set|show" command in that case.
Related-Bug: #1961740
Change-Id: I5a57cfc71ad59f1fe9ea65e19b1a32314d798729
An IP address may not have a leading zero in any of its octets, this is
getting enforced by the latest netaddr library.
Partial-Bug: 2054203
Change-Id: I15cd049de1511a9b52e8e28bccec87060c2f1411
According to the neutron API-REF [1] port's "binding:profile" field is
intended to be used for the "machine-machine communication for compute
services like Nova, Ironic or Zun to pass information to a Neutron
back-end." so it should be by allowed only for the users with the
SERVICE role granted, not even for ADMIN.
This patch updates that policies to be available only for SERVICE role
when new, secure RBAC policies are enabled.
Additionally this patch updates some policies for create, update and get
port APIs to make them all work in the same way and allow them for the
SERVICE users too.
Finally this new policy for create/update_port:binding:profile have to
be overwritten in the fullstack tests to be allowed also for admin user.
It is done by adding custom policy file for the fullstack tests only.
[1] https://docs.openstack.org/api-ref/network/v2/index.html#create-port
Closes-Bug: #2052937
Change-Id: I5c0094ff21439fe8977cfc623789a09067e6a895
There were a number of tests using variables that were
only defined in the scope of a loop, which while worked,
is undefined. No functional change.
TrivialFix
Change-Id: Ieaf6f234cf0eb747dc61c3115fdb960a708569dd
The DNS ordering and OVN DHCP documents were out-of-date
and using the old neutronclient, updated.
Noticed while fixing an openstackclient bug related to
dns_nameservers ordering.
TrivialFix
Related-bug: #2053201
Change-Id: Iab15750a4adc8dc78d839f0a1b952f9d87bdab8a
Since [1], any Neutron router created with ML2/OVN will have an
associated ``ProviderResourceAssociation`` register. The routers
created before this feature won't have any and it won't be possible
to delete them. This patch adds a temporary maintenance task to
create the needed register for these Neutron routers.
[1]https://review.opendev.org/c/openstack/neutron/+/883988
Closes-Bug: #2053122
Related-Bug: #2020823
Change-Id: Iecd5c7a66b16e25e9888dbd1e305586b2be2011e
Moved one import to the correct location, added a pylint
disable directive for another since it is intended.
No functional change.
TrivialFix
Change-Id: I5b78242c54564361492f58d30f4c546f46f53163