Relocate "_delete_expired_default_network_segment_ranges" to avoid
code redundancy.
Now instead of searching all objects and deleting one by one,
"delete_objects" is used.
Trivial-Fix
Change-Id: I1753263cb15ce2988ac4ccae03b7395069f2c4e9
In some cases it may be useful to log new vlan tag which is found
on the port when it losts old vlan tag which should is expected to
be there.
So this patch adds such value to the log message.
TrivialFix
Change-Id: I231e624f460510decc6d2237040c8bef207e2e8e
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 was proposed to be deprecated long time ago already.
We have patch ports in Openvswitch to connect bridges together.
Change-Id: Ie343f83a886bb8c366873fd5e076bb7096e1a6ed
Related-bug: #1587296
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>
Block traffic between br-int and br-physical is over kill
and will at least
1. interrupt vlan flow during startup, and is particularly
so if dvr enabled
2. if let's rabbitmq is not stable, it is possible data plane
will be affected and vlan will never work.
Using openstack on k8s particularly amplifies the problem
because pod could be killed pretty easily by liveness
probes.
Change-Id: I51050c600ba7090fea71213687d94340bac0674a
Closes-Bug: #1869808
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
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
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
Recent changes in some versions of iproute2 CLI output (v4.18),
have invalidated the regular expression used to parse the
"ip link" output.
To solve this problem and avoid future ones, pyroute2 is used to
retrieve the virtual functions information and set the VF attributes
(spoofcheck, min_tx_rate, max_tx_rate and link_state).
pyroute2 extended the "ip link" support to retrieve this information,
adding "ext_mask=1" in the get command. If no virtual functions are
present in this particular network interface, the added method,
"get_link_vfs", will return an empty list.
The set commands can return a "InterfaceOperationNotSupported" in
case the operation is not supported. For min_tx_rate, if the driver
does not support to set a minimum bandwidth, an "InvalidArgument"
(from a pyroute2.NetlinkError(22)) exception will be raised.
Change-Id: I680da4f64bd114f1caecaaeedbf8a4b1915a0849
Closes-Bug: #1878042
In case when openvswitch was restarted, full sync of all bridges will
be always triggered by neutron-ovs-agent so there is no need to check
in same rpc_loop iteration if bridges were recreated.
Change-Id: I3cc1f1b7dc480d54a7cee369e4638f9fd597c759
Related-bug: #1864822
In case when physical bridge is removed and created again it
is initialized by neutron-ovs-agent.
But if agent has enabled distributed routing, dvr related
flows wasn't configured again and that lead to connectivity issues
in case of DVR routers.
This patch fixes it by adding configuration of dvr related flows
if distributed routing is enabled in agent's configuration.
It also adds reset list of phys_brs in dvr_agent. Without that there
were different objects used in ovs agent and dvr_agent classes thus
e.g. 2 various cookie ids were set on flows in physical bridge.
This was also the same issue in case when openvswitch was restarted and
all bridges were reconfigured.
Now in such case there is correctly new cookie_id configured for all
flows.
Change-Id: I710f00f0f542bcf7fa2fc60800797b90f9f77e14
Closes-Bug: #1864822
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>
Now all Neutron ML2 drivers use OVO as input parameters to define the
allocation and the endpoints.
Reference of objects, inheritance, modifications made and presence in
other projects:
ML2TypeDriver (neutron-lib)
-> BaseTypeDriver
-> FlatTypeDriver
-> SegmentTypeDriver [1]
-> VlanTypeDriver
-> _TunnelTypeDriverBase
-> TunnelTypeDriver [2]
-> ML2TunnelTypeDriver
-> EndpointTunnelTypeDriver [3]
-> GeneveTypeDriver
-> GreTypeDriver
-> VxlanTypeDriver
[1] networking-avaya project inherits from SegmentTypeDriver, passing
the DB object instead of the OVO. This project was retired.
[2] TunnelTypeDriver class is not used anymore. networking-cisco
project imports this class if the version <= Ocata.
[3] networking-fujitsu project inherits from EndpointTunnelTypeDriver,
passing the DB object instead of the OVO. This project was retired.
Change-Id: If23d52e7839edf065619c327dc0cf47b5b560bfb
Partially-Implements: blueprint adopt-oslo-versioned-objects-for-db
With python 3.x, six.text_type and six.string_type
are just str.
Also removed a six.integer_type since it was the only
one left in a file.
Another step in removing all of six usage from neutron.
Change-Id: I5208dc41bff1983ecd323286f427296b722da62a
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
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
Zuul