This patch is responsible for creating the "ovn_hash_ring" database
table and the common methods/classes to access it.
Partial-Bug: #1823715
Change-Id: I052791cda6264baf4497e1be2bf7d3d53c49fa60
Signed-off-by: Lucas Alvares Gomes <lucasagomes@gmail.com>
Before this patch, both the sync tool and the production code
would assume that 'network:dhcp' owner ports would be for
the OVN metadata service. However, since Neutron DHCP agents
can be deployed as well on OVN environments, we need to support
these ports as well.
This change is doing several things:
- Fixing sync tool so that Neutron DHCP ports are not deleted
anymore (these ports are owned by DHCP and have a device_id
as 'dhcp<host_uuid>-<network_id>'). Syncing these ports in
OVN will no longer result in creating 'localport' ports but
normal ports to allow non-local DHCP traffic.
- Fixing networking-ovn code to skip such ports when looking
for the metadata port on a specific network.
- Newly created metadata ports will have a device_id such as
'ovnmeta-<network_id>'.
Change-Id: I30181e1752f456f30f94818c5350f447c387cbb2
Related-Bug: #1804390
Signed-off-by: Daniel Alvarez <dalvarez@redhat.com>
An operator may wish to set certain DHCP options
globally within an environment. This patch adds
configuration options to allow an operator to
specify DHCP option default values that may be
overriden by more specific configuration at the
subnet or port level.
Change-Id: I626c2dcd4ba66466b342da27a2ab50c3cac8b040
Closes-bug: 1785847
This patch registers and lists the OVN metadata agent with Neutron.
Since the OVN Controller / Gateway use the Chassis UUID as its own
agent UUID, the OVN Metadata creates can't re-use that. Instead, this
patch generates a random UUID for each Metadata agent and saves it to the
external_ids' column in the Chassis table. At startup time, the metadata
agent will check if the "neutron:ovn-metadata-id" key is present in the
Chassis external_id column and use that UUID if it's there, otherwise
it will generate a random UUID for it.
This patch uses the same AgentStats mechanism to identify whether the
OVN metadata agent is alive or not by relying on the "nb_cfg" from the
Chassis. The only difference from the OVN controller agent is that the
metadata will save the "nb_cfg" of it's last update into the Chassis
external_ids column.
Co-Authored-By: Daniel Alvarez <dalvarez@redhat.com>
Closes-Bug: #1719574
Change-Id: Icfc9e76e8371d8f33b264df65ae3a7cbc0ca099e
Instead of returning the immediate status, mimick ML2/OVS's
agent_down_time handling. With this patch, we no longer have an
issue where an agent will appear down because we didn't wait long
enough for ovn-controller to update the Chassis and we don't have
to wait before sending a response to API requests.
Closes-Bug: #1719574
Change-Id: Ib08473e4768c94ad3b0a223b72f1dad1d26769dd
When using distributed floating IPs, we set the external MAC
address and logical port fields regardless whether the LSP
is up. For the particular use of Octavia LB VIP, which doesn't
ever get bound, the floating IP associated to it will never
get the flows installed by ovn-controller.
This patch changes the mechanism so that the DNAT entries get
updated only on port up/down changes. If the port remains
down, the external_mac will be cleared and traffic to those
FIPs will still go through the centralized router.
When a port gets bound to a chassis, if DVR is enabled, the
mac_address field will be populated and traffic will go to
the compute node.
Closes-bug: #1789686
Change-Id: I0043984b4bb7b3780112aba170ffb956c48084d0
Signed-off-by: Daniel Alvarez <dalvarez@redhat.com>
Presently IPv6 functionality is broken with OVN. When a VM
sends an IPv6 Neighbor Solicitation request for the router IP,
ovn-controller when it responds with Neighbor Adv packet doesn't
set the 'router' bit in the 'flags' field. This results in the
default route getting delted. The fix [1] tried to addressed this
issue. But that fix was not completely tested in the openstack context.
ovn-northd adds Neighbor Adv flows for router IPs both in the logical
switch pipeline and logical router pipeline. The commit [1] addressed
the issue in the logical router pipeline. It should have removed the
IPv6 Neighbor Adv flows from the logical switch pipeline. The patch [2]
has been proposed upstream to remove these flows from the logical
switch pipeline. Until that is fixed in core OVN, this patch addresses
this issue in networking-ovn itself as a temporary fix (with the intention
to backport as patch [2] may not be available for OVS 2.9).
When 'add_router_interface' is called, this patch sets the router ports
peer's Logical_Switch_Port.addresses column to it's mac address instead
of 'router'. If the Logical_Switch_Port.addresses is not set to 'router',
ovn-northd will not add the Neighbor Adv flows in the logical switch
pipeline, there by mitigating this issue.
Once the patch [2] is merged, we can revert these changes.
[1] - c9756229ed (diff-2c35162acf6ad144624954fdc4c3d9f4)
[2] - https://patchwork.ozlabs.org/patch/961565/
Change-Id: I815ce0996f66f6b101c2151a8389a8b3fbe026f6
Closes-bug: #1788684
A new feature has been introduced in core OVN which allows to define
a group of ports and assign ACLs to those. This patch is making use
of the new feature if supported by the underlying OVS version.
As a result we'll be modelling Neutron Security Groups as OVN Port
Groups and we won't be adding one ACL per Security Group Rule per
port. Instead, just add one single ACL per Security Group. This will
also tackle the race conditions that we had for Address Sets as those
will just be used for Remote Security Groups and will be automatically
generated/deleted by core OVN in SB database upon Port Group creation/
deletion.
The major benefit of this patch is that we'll reduce the number of
ACL's dramatically, resulting in a performance leap as discussed at:
https://mail.openvswitch.org/pipermail/ovs-discuss/2018-February/046166.html
This patch will address the migration of old Security Groups being
modelled as Address Sets if the OVN schema supports the feature. This
migration will be performed from the OvnWorker which is holding a lock
on the IDL. This ensures that the migration happens from only one worker
in the cloud and after it's done, all the neutron-server instances are
ready to use Port Groups.
Co-Authored-By: Lucas Alvares Gomes <lucasagomes@gmail.com>
Change-Id: I35d5ec40c666e92b92b9d664e9615c6fecde595a
Signed-off-by: Daniel Alvarez <dalvarez@redhat.com>
This patch consolidades the database transactions for creating/deleting
router ports on/from the OVN NB database. Having a single transaction is
ideal to avoid inconsistencies that can be cause between two or more
transactions.
Closes-Bug: #1756388
Change-Id: I0a0a5f6571ea695b91db89170be1fab258acd917
The commit 185b13f228ac6861f567270cb9fc0bc08260ec09 from core OVN
introduced two new tables called Meter and Meter_Band to the north and
south OVN databases and a new column called "meter" in the ACL table.
These new reference is not being accounted in our tests (when comparing
the ACLs) which is breaking our functional tests. This patch fixes that.
Change-Id: I2f70a87b7e8422515c592600fa1fbd9fa45ceaa5
Instead of polling and writing updates to the Neutron DB agents
table, this patch replaces the neutron plugin agent api methods,
being sure to maintain support for multiple drivers.
Partial-Bug: #1719574
Change-Id: I43e8b0a7914e3626dd848b04fdfc54fb0351bae6
This past checks correctness when adding, removing router
interfaces, updating them, or managing the router gateway port.
For router ports, every resource (port) on the neutron side,
becomes two on the ovn side. This is why we introduce a new
type of resource to be tracked ROUTER_PORTS, and we also track
them as standard L2 PORTS.
The ROUTER_PORT resources handle the creation and update of
Logical_Router_Port and NAT resources (always going on the
same transactions).
Change-Id: I96a7e812427ebbc8e868a0e3ab78754084cdaecf
When fixing the creation or update of a resource, it's better to sort it
by its type starting with the root resources and leaving the leaf ones
at the end. For example, in case a network and a port failed to be
created, if the maintenance thread tries to create the port prior to
creating the network it will fail.
The same could happens to deletion, it's preferable to delete the leaf
resources prior to deleting the root ones to avoid any conflict.
This patch is adding such sorting mechanism to the maintenance.py database
module that is used by the maintenance task when listing the resources
that needs to be fixed.
Change-Id: Ibc8312bf70b221626e389ea68bfa4c69f6a2cb67
Partial-Bug: #1605089
This patch is updating networking-ovn to check for correctness when
creating, updating or deleting subnets.
Change-Id: I619efda775471e51bf70a63b987abf719aae995f
Partial-Bug: #1605089
This patch is updating networking-ovn to check for correctness when
creating, updating or deleting floating ips.
Partial-Bug: #1605089
Change-Id: I377007c955809b8d56af93e24f0914e446f56bb2
This patch is updating networking-ovn to check for correctness when
creating and deleting security groups.
Note that, networking-ovn doesn't care about updates on security groups
so the patch only cares about whether the security group exist or not.
Change-Id: I2add7ba1eb989fd585792c751cba4ec87f3c4974
This patch is updating networking-ovn to check for correctness when
creating, updating or deleting routers.
Partial-Bug: #1605089
Change-Id: Ida7e6100071a1e484927ca9638702e438918937a
This patch is updating networking-ovn to check for correctness when
creating or deleting security group rules.
This patch also allows to insert duplicate entries in ACL table in
case that two indentical rules belong to different SGs. Each acl will
reference to its own SG rule in the external_ids column so that we
can ensure consistency across Neutron and OVN objects. The main
drawback is that duplicated acls will make ovn-northd insert duplicate
lflows in SB database which, in turn, makes ovn-controller drop the
flows when it's processing the logical flows and log INFO messages. To
overcome this, I have sent a patch [0] to core OVN so that
ovn-controller logs those traces as DBG instead and reduce noise.
Please see the references in the commit message at [0] and the
discussion around this.
Partial-Bug: #1605089
[0] 5905b28f1a
Change-Id: Ie2659ecb84193d58d35ced6b8fb0b89fc03cf6e7
Signed-off-by: Daniel Alvarez <dalvarez@redhat.com>
This patch is refactoring the routers resource to adhere with the
database sync specification.
The update_router() method from OVNClient has been modified to not
depend on the "original_router" parameter anymore. A layer to make it
backward compatible with existing routers and OVS version < 2.8.2 was
added as well.
Partial-Bug: #1605089
Change-Id: I1744c91004fc36e0b97ebc51230f876eaaa3bd7f
This patch is updating networking-ovn to check for correctness when
creating, updating or deleting ports.
It does:
* Create the deltas using the information stored in OVNNB instead of
original_port parameter
* Save the revision number from Neutron in the ovn_revision_number table
and in OVNDB
* Expand the maintenance periodic task to detect and fix inconsistencies
for ports
Note that DNS records still can get out of sync but should be fixed by
https://bugs.launchpad.net/networking-ovn/+bug/1739257
Partial-Bug: #1605089
Change-Id: I1b2366743d76e93c8a2b19c06bcba10a3a29c7f6
Create the database model and migration scripts for saving the revision
number of the OVN objects in the Neutron database.
Update the methods related to the network resource to use the new table.
Next patches in the series will use this new table to detect when the
resource is out of sync and fix it.
Related-Bug: #1605089
Change-Id: Id14e9e8b88797acec11b72117c6985c49ea713c9
This patch is saving the revision number from the Neutron network object
into OVNDB and using it for checking for correctness when updating the
OVN resource.
The "original_network" parameter has been removed from the
update_network() methods. Since the stragey here is to drop patches with
older revision numbers we won't be creating a delta between two neutron
versions anymore. Instead, we will always make sure that OVN is sync'd
with what is latest in Neutron.
Partial-Bug: #1605089
Change-Id: Ie817a559bd708f6601d7004187f0f088e8b09b47
OVN supports Router Solicitation responder i.e it will reply to the
Router Solicitation packets. In order to use this feature, we need
to configure the Logical_Router_Port.ipv6_ra_configs column with the
appropriate values. This patch does that. When a router is added with
an interface port, these values are added.
Support to send periodic Router Advertisement in OVN is under review.
This patch also configures to use this feature by setting
Logical_Router_Port.ipv6_ra_configs:send_periodic='true'. There is no harm
in setting this in this patch.
Change-Id: I5d4d16e517d71830ea16245529dd2ba5433e0fd3
This patch is bringing logic for handling floating ips out of the L3
driver and into OVNClient.
The code now uses the ``external_ids`` column in the NAT table from
OVNDB to bind the FIP from Neutron DB with it (before we used a
combination of external + logical ips to identify those entries).
The values added in the ``external_ids`` are:
* neutron:fip_id = The ID of the FIP in neutron
* neutron:fip_port_id: This is used in the update_floatingips() method
to compare and see whether the port_id of the FIP has changed in the
update or not.
* neutron:router_name: The name of the router which the FIP is associated
with.
The ovn_db_sync.py script was updated to make use the updated methods
in OVNClient to create and delete floating IPs, that way we avoid the
code duplication that existed between this script and the L3 driver.
Partial-Bug: #1605089
Change-Id: I21e9728c93392de4c579ea00c34059ad6812f682
This patch does two things:
1. Delete the security group at the AFTER_DELETE notification level
Prior to this patch we were using the BEFORE_DELETE notification level
which can be problematic because if the deletion fails in Neutron we
would have deleted it from OVN already.
2. Remove security groups updates
The only thing that the security group updates did was to update the
external_ids of the Address_Set with its current name.
That name wasn't used for anything in networking-ovn other than knowing
whether the security group was created by networking-ovn or not.
So, instead of having the name saved in the external_ids this patch
changes it to the security group ID which is the canonical identifier of
the resource and won't change.
Partial-Bug: #1605089
Change-Id: I5a8b64639d38e11050dae1008b14d48de14ecf94
This is used to send gratuitous ARPs for SNAT and DNAT IP addresses on gateway port via the localnet port.
Change-Id: Ic16f58a4885e1327f011828fd728a6fa197d8efc
Initial implementation
Changes in the mechanism driver:
* Automatically create a port with device_owner=network:dhcp to
serve metadata and eventually DHCP.
* Auto-allocate an IP for the metadata port on subnet creation.
* Push static route for 169.254.169.254 in DHCP options.
* Wait until metadata service is provisioned in the chassis where
a port resides before sending the event to Nova.
Agent:
* Implementation of [0].
Devstack plugin:
* Starts networking-ovn-agent with the proper config files.
* Disables config drive in nova.conf for tempest against master
branch.
* Enables TEMPEST_RUN_VALIDATION for tempest against master branch.
In order to test this patch out we need to make these changes to
nova.conf:
* [DEFAULT] section:
force_config_drive = False
* [neutron] section:
service_metadata_proxy = True
This patch depends on [1] and [2] (already merged into OVS master).
NOTE: Metadata tests are only enabled for the non-voting tempest job
which runs against OVS master branch. The release job runs against
OVS 2.7 which doesn't include [1][2] so those tests are disabled
until OVS 2.8 is released.
[0]
https://docs.openstack.org/developer/networking-ovn/design/metadata_api.html
[1] https://patchwork.ozlabs.org/patch/767369/
[2] https://patchwork.ozlabs.org/patch/771297/
Change-Id: Ife2fd18f2f88050429e70c7e557fa41d2d54b034
If ls exists in OVN DB and provnet lsp doesn't, provnet lsp syncing from
neutron network(vlan or flat) is not handled.
Change-Id: I3db3d98d95791f018eb3803916dc2bee9522affd
Closes-Bug: #1671394
Signed-off-by: Dong Jun <dongj@dtdream.com>
This is a patch for supporting distributed NAT with centralized NAT rules
in networking-ovn native L3 routing.
Revise:
Remove transit network
Support scheduling gateway port by setting redirect-chassis
Support gateway sNAT
Support gateway default route
Support floating IP
Support full sync including sNAT, gateway route and floating IP
TODO:
Unit tests of syncing sNAT and FIP
Gratuitous ARP for sNAT and FIP
Closes-Bug: #1658622
Change-Id: I217d6c391140fa4392ae1cea0bc21c9ea0521796
Signed-off-by: Dong Jun <dongj@dtdream.com>
Co-authored-by: Guoshuai Li <ligs@dtdream.com>
This patch refactors networking-ovn to use portbindings
from neutron-lib. For more details see [1].
NeutronLibImpact
[1] https://review.openstack.org/422210/
Change-Id: I762b97b81752e9756b9c6f32ec9989aa3772aea0
This commit introduces the NAT support for networking-ovn. The proposal for
NAT support can be found @ [1]
TODO:
1. Add functional test cases (To be followed up in a different patch)
2. Add sync code (Opened a bug to track this)
3. Add unit tests for the new ovsdb APIs (Opened a bug to track this)
[1] https://etherpad.openstack.org/p/Integration_with_OVN_L3_Gateway
Change-Id: I9b78ceb6b42e96c1ba58ed269e369b46113edd7e
Closes-Bug: 1514995
Closes-Bug: 1551717
For v6 subnets, the 'DHCP_Options.options' in the OVN NB DB were set to empty.
This patch now sets this column for v6 subnets and also sets the
'Logical_Switch_Ports.dhcpv6_options' appropriately. If extra DHCPv6 options
are defined for a port, a new row in DHCP_Options table is created just like
the way it is done for DHCPv4.
Beside 'enable_dhcp' attribute check to a subnet, for v6 subnets, we will also
check its 'ipv6_address_mode', to make sure v6 subnets with 'slaac' as
'ipv6_address_mode' attribute value will have no DHCP_Options rows for them
be created.
Co-authored-by: Zongkai LI <lzklibj@cn.ibm.com>
Change-Id: I9cf5a7ef7676c4461c05d6cb2aabbcb95b20f4d7
Ovn Nb database requires vtep port options to be specified as follows.
The code sets the vtep keys wrongly. As a result, vtep-gw cannot
bind to the vtep port.
The port binding profile keys are also changed to
be consistent with OVN NB vtep keys.
<group title="Options for vtep ports">
<p>
These options apply when <ref column="type"/> is <code>vtep</code>.
</p>
<column name="options" key="vtep-physical-switch">
Required. The name of the VTEP gateway.
</column>
<column name="options" key="vtep-logical-switch">
Required. A logical switch name connected by the VTEP gateway.
</column>
</group>
Closes-Bug: 1624161
Change-Id: Iff51c5b2edaf0b2e5c80fafe012ec6feb495f7f3
ovn-controller stores the datapath type and supported interface
types of the host in the external_ids column of the chassis table.
When the bind_port() function is called, this patch determines the
vif_type by reading these values from the chassis row where the port is to
be bound.
If the value of datapath type is 'netdev' and has 'dpdkvhostuser' in
the supported interface types, vif_type will be set to 'vhostuser',
else vif_type will be set to 'ovs'.
The config param 'vif_type' is deprecated and no longer used.
Co-Authored-By: Richard Theis <rtheis@us.ibm.com>
Change-Id: Ia97198a5bceb5d8d39d8556346f3709846f3c5ad
Closes-bug: #1606458
This patch adds a driver interface for the trunk service plugin proposed
at https://blueprints.launchpad.net/neutron/+spec/vlan-aware-vms
One has to enable the service_plugin 'trunk' in the neutron
configuration file to try this feature.
Change-Id: I4e835e11d59cd7b9fedfdc56583b03dd2ee4c023
This patch provides the infrastructure for the OVN L3 to schedule
the router gateway port. The OVN hypervisor administrator can
set aside certain hypervisors to be used for scheduling router
gateway ports. This is the corresponding WIP patch at the moment:
http://openvswitch.org/pipermail/dev/2016-June/073285.html
For now it is assumed that any hypervisor/chassis can host a router
gateway port.
There are 2 types of schedulers defined at the moment
(1) RandomChoice
(2) LeastLoaded
The Chassis (add/delete/update) event is used to schedule router
gateway ports which have not been bound to any chassis.
A future patch will add functional tests.
Change-Id: I83fb561cee642b90c4de41bb8e472f47fa807191
Related-Bug: 1514995
Add OVN address set support for implementing remote security
groups. This should significantly improve performance of port
create, update and delete operations when remote security
groups are used (see [1]).
[1] http://paste.openstack.org/show/526972/
Bug #1600330 has been added for the follow-on work to update
the OVN NB DB sync tool.
Co-Authored-By: Richard Theis <rtheis@us.ibm.com>
Change-Id: I56e9eb1ded1836b9a9f7262f22daa51103bc8518
Closes-bug: #1560817
This patch adds support for flat and vlan provider networks using the
standard Neutron provider networks API extension. The document on
testing with devstack has also been updated to cover how to test
provider networks.
For more information about how this works in OVN, see these commits:
c02819293d779e72cc57
or go through this OVN tutorial to the "locally attached networks"
sections:
https://github.com/openvswitch/ovs/blob/master/tutorial/OVN-Tutorial.md
Related-bug: #1474977
Change-Id: I9bbd51e8f8c0e16d6a2cdb54ae0979889bf73dcc
Signed-off-by: Russell Bryant <rbryant@redhat.com>
This patch adds support for integrating VTEPs in neutron. The idea is to
use the "--binding-profile" parameter in port-create to specify the VTEP
details.
neutron port-create --binding-profile
'{"vtep_physical_switch":"PSW1","vtep_logical_switch":"LSW1"}' private
The above command will result in creation of a row in OVN NB Logical
Port table with type column set
to 'vtep', the option column set to
'vtep_physical_switch:"PSW1",vtep_logical_switch:"LSW1"', macs column
set to [unknown] and port_securtiy column set to []
_uuid enabled external_ids
macs name options
parent_name port_security tag type up
------------------------------------ ------- ------------------------
--------------------- --------------------------------------
--------------------------------------------------------- -----------
--------------------- --- ---- -----
547934d0-8069-455d-b064-105a8d3455ea true {"neutron:port_name"=""}
[unknown] "e1b8a373-516d-43df-8cd5-de16341c466b"
{vtep_logical_switch="LSW1", vtep_physical_switch="PSW1"} [] []
[] vtep false
Also added few unit test cases
Change-Id: I6b642af74fc693bb92c3475fb862c3bf7477213c
Co-Authored-By: Amitabha Biswas <abiswas@us.ibm.com>
Related-Bug: #1457569
Sync all changed neutron objects to OVN-NB DB.
Remove from OVN-NB DB objects that are not found in neutron but
have neutron external ids
Change-Id: I7f0b0a728894f38006654e8d5f4599aec51af0c4
Lucas Alvares Gomes
Daniel Alvarez
Andrew Austin
Terry Wilson
Numan Siddique
Miguel Angel Ajo
Changxun Zhou
Dong Jun
Boden R
Chandra S Vejendla
Ramu Ramamurthy
Babu Shanmugam
Amitabha Biswas
Han Zhou
Gary Kotton
Russell Bryant
Gal Sagie