Since [1], "get_subnet_dhcp_options" returns always a dictionary
in "subnet" instead of None. This patch checks not only that "subnet"
is None but also the dictionary is not empty.
[1]https://review.opendev.org/c/openstack/neutron/+/807692
Closes-Bug: #1948466
Change-Id: Ie93cf3e47e09b3e5051be1ffad512251775b0492
(cherry picked from commit 95c2801da8)
OVN Driver currently fixes gateway_mtu MTU to the provider MTU value
without considering if the private networks in the associated router
have greater MTU values than the provider. This is unnecesary and
adds extra actions for each packet. This patch fixes that, as now
gateway_mtu is only set in case the provider MTU is smaller than the
private MTU.
The changes in create_router_port and delete_router_port were necessary
as there could be a use case when the user first sets the gateway
router and later adds subnets from networks with greater MTU, so this
parameter needs to be checked after adding a subnet.
Closes-Bug: #1951559
Signed-off-by: Elvira García <egarciar@redhat.com>
Change-Id: If56f1a3dcdc8c57303d5641df79ea919ba7c170d
(cherry picked from commit 0725533a6f)
In order to avoid having a MAC_Binding table explosion and helping
lowering the memory footprint when using ML2/OVN this patch is setting
two options to the OVN routers:
* always_learn_from_arp_request: By setting this to False we
avoid learning from ARP replies observed in the network. Only the
ARP requests sent by OVN will generate a MAC_Binding entry in the
OVSDB database. For larger broadcasts domains this avoids having a
MAC_Binding table explosion, reduce the DB size and memory footprint
of ML2/OVN.
* dynamic_neigh_routers: By setting this to True we avoid
pre-populating flows for router to router communication, reduding
the number of flows, DB size and memory footprint of ML2/OVN.
For more information on these option for core OVN please refer to:
https://www.ovn.org/support/dist-docs/ovn-nb.5.html
This patch also includes a new maintenance task to include these options
to existing routers in the system.
Related-Bug: #1946318
Change-Id: I056acdec9b6ee2341d2bc4f7bd9a678f3bf91972
Signed-off-by: Lucas Alvares Gomes <lucasagomes@gmail.com>
(cherry picked from commit a278c5ba78)
Always update the DHCP options when the metadata port is created,
updated or deleted. If the metadata port IP addresses are updated,
the DHCP options register should be too, modifying the static routes
defined in "DHCP_Options.options.classless_static_route".
These static routes will be injected in the VM in the DHCP request.
The IP address of the metadata port should match with the static
route redirecting the traffic to the metadata IP address
"169.254.169.254/32":
$ ip r
default via 10.0.0.1 dev eth0
10.0.0.0/28 dev eth0 scope link src 10.0.0.7
169.254.169.254 via 10.0.0.2 dev eth0 # 10.0.0.2 is the metadata
# port IP address
Conflicts:
neutron/plugins/ml2/drivers/ovn/mech_driver/ovsdb/ovn_client.py
neutron/tests/functional/plugins/ml2/drivers/ovn/mech_driver/test_mech_driver.py
neutron/tests/unit/fake_resources.py
Closes-Bug: #1942794
Change-Id: Id5d4909caa521a899b97d83bdc1963b010e97dac
(cherry picked from commit bd0ded15ca)
(cherry picked from commit 7efce62b4f)
(cherry picked from commit f4dd0b80ac)
When a subnet does not have DHCP configured, the metadata port does
not have an IP address on this CIDR. The method
"OvnNbSynchronizer.sync_networks_ports_and_dhcp_opts", was always
setting an IP address for the metadata ports, regardless of the subnet
configuration (with or without DHCP).
The method "_sync_metadata_ports", in charge of synchronizing the
metadata ports, now filters the subnets by the parameter "enable_dhcp".
In case of having a subnet with DHCP enabled, if the metadata port is
missing the subnet IP addresses, the method adds them.
In case of having a subnet without DHCP enabled, if the metadata port
has an IP address on the subnet, the method removes it.
Closes-Bug: #1939726
Conflicts:
neutron/plugins/ml2/drivers/ovn/mech_driver/ovsdb/ovn_client.py
Change-Id: I09cc14dff6933aae63cbd43a29f9221f405ecede
(cherry picked from commit 5e32dddc11)
(cherry picked from commit fe9e596d3e)
This patch changes the get_candidates_for_scheduling() method to also
consider all gateway chassis as potential candidates (limited by
Availability Zones) in case physnet parameter is empty (as for the
segmented networks case).
This patch is a simpler/backportable fix for the segmented networks +
Router AZs use case. In the future we should consider refactoring the
code responsible for scheduling the gateway router ports, a more detailed
explanation of what is happening/needed can be found at LP #1939144.
Change-Id: I8dc5336c6e2acd0b0a2cad0e80eee91280b9f945
Closes-Bug: #1939144
Signed-off-by: Lucas Alvares Gomes <lucasagomes@gmail.com>
(cherry picked from commit 8ac9e2fe6d)
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
Conflicts:
neutron/plugins/ml2/drivers/ovn/mech_driver/mech_driver.py
neutron/plugins/ml2/drivers/ovn/mech_driver/ovsdb/ovsdb_monitor.py
neutron/tests/functional/plugins/ml2/drivers/ovn/mech_driver/test_mech_driver.py
Change-Id: I1f5af36b8c3d5650f890edfed3c33dc206869824
Signed-off-by: Jakub Libosvar <libosvar@redhat.com>
(cherry picked from commit d7c23431ad)
The mcast_flood option will unconditionally forward multicast traffic
for that port, this behavior is not desired and results in duplicated
traffic being sent to the same port. This patch disables that behavior
by setting the mcast_flood option for the localnet ports to False.
Note that, a similar option called "mcast_flood_reports" is still
enabled because we do want to have the multicast reports being sent but
not normal traffic.
Change-Id: I8033e12f5b30e3ecc9143431543266a890fe4073
Closes-Bug: #1933207
Signed-off-by: Lucas Alvares Gomes <lucasagomes@gmail.com>
(cherry picked from commit 953eb92a4f)
This patch removes a conditional check in the update_router() method
which was verifying if snat was enabled in order to update the nat
rules. This check does not make sense in the update method as if snat
was disabled we should still call update_nat_rules() which will then
remove the NAT entry from the OVN NB DB.
Change-Id: Ice20d22365acaf33ee211b1e38b7d0bc151c1ba8
Closes-Bug: #1922089
Signed-off-by: Lucas Alvares Gomes <lucasagomes@gmail.com>
(cherry picked from commit ddc8e625f7)
Since [1] and [2] OVN supports DVR on VLAN networks with usage of
external-ids:ovn-chassis-mac-mappings, but reside-on-redirect-chassis
needs to be unset when distributed floating IP is enabled.
[1]: 1fed74cfc1
[2]: 522911269f
Closes-Bug: #1920976
Change-Id: I68b9a586d1d7ec75820fedcb8e51d1c49ae871ae
(cherry picked from commit 8287654127)
(cherry picked from commit b956411b6c)
OVN QoS extension do not manage the external type ports (SR-IOV);
the port QoS policy of those ports is handled by the SR-IOV agent
QoS extension.
Conflicts:
neutron/plugins/ml2/drivers/ovn/mech_driver/ovsdb/extensions/qos.py
neutron/tests/unit/plugins/ml2/drivers/ovn/mech_driver/ovsdb/extensions/test_qos.py
Change-Id: Ibd1caf34a5f707f5ae9ff5973860d4e8338ef224
Closes-Bug: #1918702
(cherry picked from commit f700660b6b)
MAC learning has been added in OVN v21.03[0]. Now, if DHCP and port
security are disabled, then the addresses field of a port should not
include its MAC-IP address pairs. This allows the use of OVN MAC
learning capabilities. Existing tests now match this requirement too.
[0] http://patchwork.ozlabs.org/project/ovn/list/?series=228135i&state=%2A&archive=both
Change-Id: I485762b46567a99b9ebd6eb047c7088fed8071d1
Closes-Bug: 1904412
Signed-off-by: Elvira García Ruiz <egarciar@redhat.com>
(cherry picked from commit 24fddc760e)
This commit makes the delete_router_port() method from OVNClient more
resilient to NotFound errors. Apart from the L3 plugin, this method is
also invoked by the maintenance task to fix stale/not-up-to-date objects
in the OVN database, and since the maintenance task runs every 5 minutes
only it could happen that some objects fetched by delete_router_port()
are gone by the moment that method is invoked.
Change-Id: I0d78278797beb2af42ec38462e2b2edc8e2a4ae6
Closes-Bug: #1920968
Signed-off-by: Lucas Alvares Gomes <lucasagomes@gmail.com>
(cherry picked from commit 36b8c684b1)
This patch adds a check prior to setting the send_periodic configuration
option for the LRP's ipv6_ra_configs to see if the network the LRP is
connected to is a provider network and the port is a gateway port.
In case it is a provider network and the port is a gateway port,
send_periodic should be set to False to avoid leaking the RAs generated
by ovn-controller to the tenant networks onto the provider network.
Closes-Bug: #1919347
Change-Id: I4e1ffb3a1eea147a750def245f869aca9e036b88
Signed-off-by: Lucas Alvares Gomes <lucasagomes@gmail.com>
(cherry picked from commit 1f68336b79)
This patch enables the "mcast_flood_reports" and "mcast_flood" (on provnet
ports only) options in the Logical Switch Ports in the OVN driver. Without
these options, the ovn-controller will consume the IGMP queries and won't
send it to the LSP ports, meaning that external IGMP queries will never
arrive to the VMs.
In talks to the core OVN team, it was suggested [0] to enable the
"mcast_flood_reports" option by default in the OVN driver (at least until
fixed in core OVN) as a workaround to this problem. And, to avoid having
to update all ports (which can be many) based on the igmp_snooping_enable
configuration option, we are always setting "mcast_flood_reports" to
"true" in the LSPs. This won't cause any harm (also confirmed by core
OVN developers [0]) since it will be ignored if multicast snoop is
disabled.
[0] https://bugzilla.redhat.com/show_bug.cgi?id=1933990#c3
Closes-Bug: #1918108
Change-Id: I99a60b9af94b8208b5818b035e189822981bb269
Signed-off-by: Lucas Alvares Gomes <lucasagomes@gmail.com>
(cherry picked from commit b04d64b90f)
When a subnet is updated or created, the metadata port is updated too,
to add the fixed IP address of the new subnet. In this case, the port
should update only the IP address of this specific subnet.
Change-Id: I05394e49077a72199bbc80c8cb622ec2b17f2fa7
Closes-Bug: #1890432
(cherry picked from commit 93225e016b)
Prior to this patch the IGMP configuration for ML2/OVN was inconsistent
with the configuration option description and also the ML2/OVS driver
because it was flooding traffic to unregistered VMs [0].
The "igmp_snooping_enable" configuration option says:
"Setting this option to True will also enable Open vSwitch
mcast-snooping-disable-flood-unregistered flag. This option will disable
flooding of unregistered multicast packets to all ports."
But, in ML2/OVN that behavior was inconsistent prior to this patch
because it allowed traffic to flood to unregistered VMs. This patch
fixes it.
Conflicts:
neutron/plugins/ml2/drivers/ovn/mech_driver/ovsdb/ovn_client.py
neutron/tests/functional/plugins/ml2/drivers/ovn/mech_driver/ovsdb/test_maintenance.py
neutron/tests/unit/plugins/ml2/drivers/ovn/mech_driver/test_mech_driver.py
[0]
https://opendev.org/openstack/neutron/src/branch/master/neutron/conf/agent/ovs_conf.py#L36-L47
Change-Id: I5cbe09e26120905b29351d61bbadb30b5dd14938
Closes-Bug: #1904399
Signed-off-by: Lucas Alvares Gomes <lucasagomes@gmail.com>
(cherry picked from commit 9dc8bca740)
Prior to this patch, the OVNClient implementation for neutron's
update_port was setting the external_ids of the affected logical
switch port to a hard-coded dictionary. This meant that any key
value pairs that were not listed there would simply get removed.
This would make it impossible for any other users of the
external_id to have a reliable way of storing its data. One of
such users could be the ovn-octavia-provider.
Note: mock module does not exist in stable/victoria and master,
thus the conflict below.
Conflicts:
neutron/tests/functional/plugins/ml2/drivers/ovn/mech_driver/ovsdb/test_ovn_db_resources.py
Closes-Bug: #1896827
Change-Id: Ie580534e4d91f1ca2e1dc8331632d49d4720e7ba
(cherry picked from commit be3669258c)
From "strip" documentation:
Return a copy of the string with leading whitespace removed.
If chars is given and not None, remove characters in chars instead.
Change-Id: Ia1bf0a98b327b4deaa4ff87da79b70d27314434a
Closes-Bug: #1888828
(cherry picked from commit fc5a8ee1b8)
While port has QoS policy configured the policy wasn't deleted
because of logic issue.
Change-Id: I3d7e70a4a110c68a89d6c575abf121cd9b97e439
Closes-Bug: #1886962
(cherry picked from commit 0e53673c5d)
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>
(cherry picked from commit 26f6b90930)
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>
(cherry picked from commit d669dff1dc)
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
(cherry picked from commit 9cbbd8de53)
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
(cherry picked from commit 483f468fdd)
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
(cherry picked from commit e6023ecb48)
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>
(cherry picked from commit 8b234d8786)
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
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 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
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
This patch reverts [0].
The code wasn't accounting for VLAN provider networks, as stated in the
bug #1842988, DVR won't work if the provider network (where the FIP is
created) is VLAN.
There was also an incosistency in how the external_mac was set for the
VLAN networks. Upon creating the FIP the code was checking for the
network type and not setting the external_mac attribute in case the
network was VLAN type. But, if the port went down and up again (e.g if
you reboot the VM) the event handler that set/unset the external_mac [1]
wasn't check for the type. This is how people worked around the DVR
problem (as stated in bug #1842988).
For more information see bug #1842988.
[0]
c5aef51edc
[1]
eda5d7f80d/networking_ovn/ml2/mech_driver.py (L794-L800)
Change-Id: Ifb795626dc9c2ac4f0104f491dd38c9b4cc902c9
Closes-Bug: #1842988
Signed-off-by: Lucas Alvares Gomes <lucasagomes@gmail.com>
For now while updating FIP check if port or logical_ip
has changed and only then we deleted the NAT entry.
Unfortunately each time when FIP update occurs the
method _create_or_update_floatingip() is used. It first deletes
LSP pointed by FIP and adds it again along with new NAT entries.
Based on author comment this actions are required.
So if we don't update FIP with logical_ip or new port_id,
like update a description, the NAT entries gets duplicated.
Since all is wrapped withing a transaction and to not wait for
proper fix (this code need sa refactor based on commments with NAT
external_id column) I think thats safe just to delete the NAT entry
in such situation like described above.
Change-Id: Iea532e2a02b7992305d1b90aa040e064901c340c
Related-Bug: #1859977
This context was required but not passed. This change adds it.
Change-Id: I5e5e14d5a621fc4a790810d15e1162f90898282e
Related-Blueprint: neutron-ovn-merge
Previous to this patch, the 'unknown' address was added to the
OVN Logical_Switch_Port row. However, the '<ip> <mac1> <macN>'
was still there so the port security was not really disabled.
The correct behavior is to set the 'addresses' field to 'unknown'
and remove everything else.
Change-Id: I0b84f41865e3fdea49cf169df5431249c35f5ff8
Closes-Bug: #1728886
Signed-off-by: Daniel Alvarez <dalvarez@redhat.com>
Rodolfo Alonso Hernandez
Elvira García
Lucas Alvares Gomes
Jakub Libosvar
Michał Nasiadka
Flavio Fernandes
Maciej Józefczyk
Brian Haley
zhangyuhe
zhanghao
Daniel Alvarez
zhufl