OVN's API called get_port_groups is poorly named and has misleading docstring.
It returns only the OVN port groups that map to the security group in Neutron.
Therefore, it should be called get_sg_port_groups.
Closes-Bug: #1883716
Related-Bug: #1881316
Change-Id: Iae3f413dd1c4b0813b05d9bfd593c9e709540370
Signed-off-by: Flavio Fernandes <flaviof@redhat.com>
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>
While the segments plugin is not loaded in neutron config, it should
be loaded anyways in OVN maintanance task, to operate on the first
default segment of each network.
Change-Id: Ideffacc2f478c95eeec881c82d1d5bae46ecdc74
Closes-Bug: 1883193
As stated in the bug description, there are many writes of the
agent liveness external_ids into the Chassis table. There was a
protection to avoid bumping nb_cfg too frequently.
The same protection is reused to avoid writing into the Chassis
external_ids.
This patch reduces the number of transactions to the SB database
and, therefore, the recomputations that it causes to ovn-controller
in all nodes.
Change-Id: I5db90fde8e7394772ec23c6384c711096c246621
Closes-Bug: #1883554
Signed-off-by: Daniel Alvarez <dalvarez@redhat.com>
Prior to this patch, if the [ovn]/enable_distributed_floating_ip
configuration option changed in an existing environment the OVN
driver wouldn't adapt to it requiring administrators to clear up the
"external_mac" column from the NAT table manually for the existing
floating ips.
With this patch, OVN will automatically correct existing NAT entries for
floating ips whenever this option changes.
To make the code simpler when handling the port up/down event this patch
always set the logical_port and the neutron:fip_external_mac key in the
external_ids column of the NAT entry when creating the floating ip.
Note that we are not using the maintenance task for this either, we are
re-using the event that set/unset the "external_mac" column for this
because, whenenver the service is restarted (after the configuration is
changed, we need to restart for it to take effect) the IDL will re-trigger
those events.
Closes-Bug: #1883559
Change-Id: I6a85fdde2558d781bf2853c5d11c5c964bbab81f
Signed-off-by: Lucas Alvares Gomes <lucasagomes@gmail.com>
Port_Groups table has been introduced in OVN 2.10 and we've moved in
master to newer version since. This patch removes all references to code
branching between port_groups and address_sets, and also removes
unneeded Address_Set commands and references.
Change-Id: I592d31db9be76d9be202d79d942e15b1668e3c0e
If new segment is created/old deleted we should update its
localnet port in related Logical_Switch.
Added also missing code to sync tool in order to delete provnet
ports in case of leftovers.
Change-Id: I6b864ba1c168643640a64bd7c25e1d0fc0ea348a
Related-Bug: 1865889
Because of broken check why one port has similar address to the other
one, the first one by mistake could be set as virtual.
Example:
port_1: 10.11.1.100
port_2: 10.11.1.10
On create of port_2 it is set as 'virtual', but shouldn't.
This patch fixes that bug by using common function
utils.get_ovn_port_addresses().
Change-Id: Ia4b986146c77edf0616015380359e37233df80fc
Closes-Bug: #1881759
Prior to this patch OVN did not validate any extra DHCP option passed
to the port leading to confusion because the user of the API could just
input any value and OVN would accept it (returning 200) but ignoring the
option internally.
This patch now adds such validations on port creation and update.
This patch also sync with the latest supported DHCP options from OVN and
create a map between the different names and option codes to their OVN
counterpart.
Closes-bug: #1874282
Change-Id: I99799e54e941cdd8da2614feecad1ef6299703fc
Signed-off-by: Lucas Alvares Gomes <lucasagomes@gmail.com>
With python 3.x, classes can use the metaclass= logic
to not require usage of the six library.
One step in removing all of six usage from neutron.
Change-Id: I2f815e412d9a96eb5faf2b3bb3a1e393a9db9309
We override ovsdbapp's Backend class to change from using a class
variable for the ovsdb_connection to using an instance variable.
This means we have to override several different methods/properties.
This could be simplified in ovsdbapp by making ovsdb_connection a
property, which in ovsdbapp access a class variable, and in neutron
it is overridden to to store on the instance, so there would be
less to override.
ovsdbapp is adding user-definable indexed columns so things like
lookups by name will be faster. Due to the way it is architected,
the place to generate the indexes would be just before the
connection starts. Since methods like start_connection are
classmethods in ovsdbapp, and instance methods in neutron, this is
hard to do cleanly w/o ovsdb_connection being a property. Without
this change, neutron would fail if that property was defined. With
the change, it should pass with both old and new code.
Change-Id: Idd184807de24c79dd892046f01e3acdd1168ca2d
This patch is making the transaction from the _delete_port() method in
OVNClient more resilient to errors where elements from that transaction
have already been deleted by another change in the database.
Prior to this patch, a few places could potentially raise RowNotFound
which would abort the whole transaction and would leave the a stable
port for being cleaned up after by the maintenance thread. This patch
tries to catch those exceptions that could potentially fail the
transaction.
Change-Id: I8fd1d1485269d23529a19085bd4aa4c6c74f5f91
Partial-Bug: #1874733
Signed-off-by: Lucas Alvares Gomes <lucasagomes@gmail.com>
OVNL3RouterPlugin inherits from L3_NAT_dbonly_mixin, which inherits
from neutron.extensions.l3.RouterPluginBase
As maintenance task expects OVNL3RouterPlugin to behave as
RouterPluginBase, the add_router_interface should have the signature:
add_router_interface(self, context, router_id, interface_info)
Note: With this change, the default behavior of OVNL3RouterPlugin's
_add_neutron_router_interface becomes idem-potent: multiple calls to add
the same interface will not fail. Because of that, the unit test
test_router_add_interface_dup_port no longer makes sense and is being
removed.
Closes-Bug: #1876148
Change-Id: I8010113b4d8c66ecbccf3126f322a8836d92e7ba
Signed-off-by: Flavio Fernandes <flaviof@redhat.com>
The patch adds a short living connection in pre-fork routine that
creates neutron_pg_drop Port Group. Later after workers are spawned,
each worker also creates a short living connection and waits for an
event that the Port Group was created.
The short living IDLs limit its tables only for relevant tables so it
doesn't fetch the whole OVS DB to the local copy.
Closes-bug: #1866068
Change-Id: I1f5af36b8c3d5650f890edfed3c33dc206869824
Signed-off-by: Jakub Libosvar <libosvar@redhat.com>
The delete_port() method from OVNClient has a potential problem of
leaving stale ports when RowNotFound is raised from the process to
delete the port from the OVN database. Since the exception is not
granular enough, the RowNotFound could be raised from other objects that
are part of the same transaction (such as ACLs, DNS entries, etc...)
resulting in the revision for the port being deleted even tho the port
is still in the database.
Instead of giving a pass on the RowNotFound exception, this patch is
logging the error and re-raising it without deleting the revision.
Change-Id: I25b93b7c080403fc38365b638e4e03298b447d0f
Partial-Bug: #1874733
Signed-off-by: Lucas Alvares Gomes <lucasagomes@gmail.com>
Prior to this patch, the OVN driver wasn't account for the VNIC types
VNIC_DIRECT_PHYSICAL and VNIC_MACVTAP. These types should work the same
way as the VNIC_DIRECT type in the OVN driver perspective.
Closes-Bug: #1874065
Change-Id: Idb596b5a80a3155bc9cdee1e082506701e730f00
Signed-off-by: Lucas Alvares Gomes <lucasagomes@gmail.com>
The QoS OVN client extension is moved to the ML2 driver. This
extension is called from the OVN driver in the events of:
- create port
- update port
- delete port
- update network
The QoS OVN client extension now can accept several rules per policy
as documented in the SUPPORTED_RULES. The QoS OVN client extension
can write one OVN QoS rule per flow direction and each OVN QoS rule
register can hold both a bandwidth limit rule and a DSCP marking rule.
The "update_policy" method is called from the OVN QoS driver, when
a QoS policy or its rules are updated.
The QoS OVN client extension updates the QoS OVN registers
exclusively, based on the related events.
Closes-Bug: #1863852
Change-Id: I4833ed0c9a2741bdd007d4ebb3e8c1cb4c30d4c7
Only reschedule gateways/update segments when things have changed
that would require those actions.
Co-Authored-By: Terry Wilson <twilson@redhat.com>
Change-Id: I62f53dbd862c0f38af4a1434d453e97c18777eb4
Closes-bug: #1861510
Closes-bug: #1861509
We can now revert this patch, because main cause has been already
fixed in Core OVN [1]. With this fix the ARP responder flows are not
installed on LS pipeline, when LSP has port security disabled, and
an 'unknown' address is set in addresses column.
This makes MAC spoofing possible.
[1] https://patchwork.ozlabs.org/patch/1258152/
This reverts commit 03b87ad963.
Change-Id: Ie4c87d325b671348e133d62818d99af147d50ca2
Closes-Bug: #1864027
The "old" parameter passed to the handle_ha_chassis_group_changes()
method is a delta object and sometimes it does not contain the
"external_ids" column (because it hasn't changed).
The absence of that column was misleading that method into believe that
the "old" object was no longer a gateway chassis and that triggered some
changes in the HA group. Changing the HA group resulted in the SRIOV
(external in OVN) ports to start flapping between the gateway chassis.
This patch is adding a check to verify that the "external_ids" column
has changed before acting on it, otherwise just ignore the update and
return.
Closes-Bug: #1869389
Change-Id: I3f7de633e5546dc78c3546b9c34ea81d0a0524d3
Signed-off-by: Lucas Alvares Gomes <lucasagomes@gmail.com>
Add a default value to the max() built-in method while looking for the
highest priority chassis in the HA Chassis Group and to avoid the
following error:
2020-03-20 10:05:35.160 27 ERROR futurist.periodics File
"/usr/lib/python3.6/site-packages/futurist/periodics.py", line 293, in
run
2020-03-20 10:05:35.160 27 ERROR futurist.periodics work()
2020-03-20 10:05:35.160 27 ERROR futurist.periodics File
"/usr/lib/python3.6/site-packages/futurist/periodics.py", line 67, in
__call__
2020-03-20 10:05:35.160 27 ERROR futurist.periodics return
self.callback(*self.args, **self.kwargs)
2020-03-20 10:05:35.160 27 ERROR futurist.periodics File
"/usr/lib/python3.6/site-packages/futurist/periodics.py", line 181, in
decorator
2020-03-20 10:05:35.160 27 ERROR futurist.periodics return f(*args,
**kwargs)
2020-03-20 10:05:35.160 27 ERROR futurist.periodics File
"/usr/lib/python3.6/site-packages/neutron/plugins/ml2/drivers/ovn/mech_driver/ovsdb/maintenance.py",
line 576, in check_for_ha_chassis_group_address
2020-03-20 10:05:35.160 27 ERROR futurist.periodics high_prio_ch =
max(default_ch_grp.ha_chassis, key=lambda x: x.priority)
2020-03-20 10:05:35.160 27 ERROR futurist.periodics ValueError: max()
arg is an empty sequence
Change-Id: Ifeb1ed8a4eac1d2c34a2d1d306a41708d80b4110
Signed-off-by: Lucas Alvares Gomes <lucasagomes@gmail.com>
The check _is_virtual_port_supported() prevented us from
clearing the addresses field while port was OVN LB VIP port.
The virtual port should be set only when port is Octavia Amphorae
VIP port.
Change-Id: Id6dd29650951855d13498a7206f6d1dde7db7864
Closes-Bug: 1863893
The OVN maintenance code was not always calling into
the OVNClient class methods with the correct number of
arguments, leading to exceptions.
After a deeper review, there were a number of places
where this was happening, so changed most methods to
take a 'context' argument since it's usually available
in the caller.
Change-Id: I1bcb0ca68747e4c32523e41307dc132291c55f6d
Closes-bug: #1861502
It is possible to re-use the mech driver ovsdb connections in the
ovn l3 plugin, saving the overhead of two db connections/in-memory
copies of the db per process.
Closes-Bug: #1864548
Change-Id: I022dea485f42cf76c4cec67ee43eed9a3770ec9c
This patch introduces a new mechanism to allow rerunning maintenance
tasks upon an OVN database schema change to avoid a service restart.
As an example, the "migrate_to_port_groups" maintenance task will run
again when the database schema is updated. In case of a migration from
an OVN version without port groups support to a version that supports
it, the OVN driver will migrate the code automatically without the need
of a service restart.
Closes-Bug: #1864641
Change-Id: I520a3de105b4c6924908e099a3b8d60c3280f499
Signed-off-by: Lucas Alvares Gomes <lucasagomes@gmail.com>
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>
- This change fixed an issue where the update_router_routes method
would not execute when all static routes were removed
Closes-Bug: #1860273
Change-Id: I33559947f63ab4259ec99f093350e8e6eeb83d7d
Signed-off-by: zhangyuhe <1073258077@qq.com>
The 'port_object' needs to be removed, so the current security group
dependency on it needs to be resolved first. The 'security_group_ids'
has been stored in the 'external_ids' of the logical switch port. When
updating or deleting a port, the security groups can be obtained directly
from 'ovn_port'.
Change-Id: I764f3426fe0e38094b77b69f4cb752d042f4d701
Partial-Bug: #1863987
When Load Balancer and its member has FIP assigned
and environment is configured to use DVR the member
FIP needs to be centralized. It is current core OVN
limitation, that should be solved in [1].
This patch adds this mechanism to OVN Client and
OVN Octavia provider driver.
It covers cases:
1) FIP association on port that is a member of
some LB - make it centralized.
2) FIP association on LB VIP - find a members
FIPs and centralized them.
3) Add a member to LB that has FIP already
configured - checks if a member has FIP
and centralize it.
4) The reverse of each of the above cases.
In addition I needed to extend OVN LB member external_id
entry to add an information about member subnet_id
in order to easly track member port from mechanism OVN
driver.
That means I needed also to support both old and new
conventions. This patch adds also this code.
Old convention:
member_`member_id`_`ip_address`:`port`
New convention:
member_`member_id`_`ip_address`:`port`_`subnet_id`
[1] https://bugzilla.redhat.com/show_bug.cgi?id=1793897
(Cherry-picked from networking-ovn 57ac38921efa6bbf0bc4a22950355256cc3ebe6d)
Related-Bug: #1860662
Change-Id: I254f0ac28f7585b699a8238e01ffb37dd70282ef
If QoS rule is QosBandwidthLimitRule, then the generated options in
the QoS OVN driver of the QoS service should contain those two
parameters: "qos_max_rate" and "qos_burst".
According to [1], the units used are:
- qos_max_rate: kbps, the one used in Neutron
- qos_burst: kilobits, the one used in Neutron
A "rule.max_kbps" value should be always present in the rule, but not
"rule.max_burst_kbps". This value can be None in
OvnNbApiIdlImpl.QoSAddCommand.
[1]http://www.openvswitch.org/support/dist-docs/ovn-nbctl.8.html
Change-Id: Ie1598be7d21f33df6b1a66fa71ba6783d2433dca
Closes-Bug: #1861680
Zuul