This reverts commit 6fa3d8019f.
Reason for revert: https://bugs.launchpad.net/neutron/+bug/2025126
A new SLQAlchemy/alembic (master branch) version reverted the
behaviour fixed in the patch that is being reverted.
Closes-Bug: #2025126
Change-Id: I9322589d973d9469d92878a505de6133978ade84
The alembic comparator needs the same class to compare the
database model with the loaded SQL schema.
Closes-Bug: #2020050
Change-Id: I4feab3e55f2e38a9eca70d4ca755b4c2974346d5
We observe excessive DB calls to load DistributedPortBindings,
We have enabled DVR and have some huge virtual routers with around
60 router interfaces scheduled on around 200 compute nodes. Under such
situation, subquery load DistributedPortBinding looks like not a very wise
idea, because it is not explicitly used.
I glance through the code and have a feeling that ml2_distributed_port_bindings
is not used except explicitly called. So IMO it is safe to change it to
default lazy load without causing serious regression.
Closes-bug: #1973576
Change-Id: Ib2c48bd5ad55e9c754a8e4938e6c5eafacc75dcc
As a consequence of implementing multiple bindings for ports, [1] made
the following attributes lists:
- 'port_binding' in the in the SQLAlchemy Port model
- 'binding' in the Port OVO
This patch pluralizes their names to 'port_bindings' and 'bindings'
respectively
[1] Ie31d4e27e3f55edfe334c4029ca9ed685e684c39
Change-Id: I4ebe47cf9d51a700310aad8dcccc82fea3f00a16
Functionality is added to the ML2 plugin to handle multiple port
bindings
Co-Authored-By: Anindita Das <anindita.das@intel.com>
Co-Authored-By: Miguel Lavalle <miguel.lavalle@huawei.com>
Partial-Bug: #1580880
Change-Id: Ie31d4e27e3f55edfe334c4029ca9ed685e684c39
The test class was not inheriting from testlib_api.SqlTestCase which
means that the test cases were never executed.
Once it was executed, it became obvious that the object has an issue
with SQL query scalability. Specifically, it was failing the
test_get_objects_queries_constant test case that validates that the
number of queries to fetch a single object is the same as for multiple
objects. This happens because PortBindingLevel's 'segment' synthetic
field is not constructed from db model relationship but through issuing
a get_object OVO call that triggers a query per fetched PortBindingLevel
object.
To fix the issue, the patch added a new 'segment' relationship to
PortBindingLevel db model, and made OVO use attributes from the
relationship to construct 'segment' synthetic field.
Another issue revealed by enabling the test class is that foreign_key
definition for the 'segment' synthetic field located in NetworkSegment
object refers to 'segment_id' field but the field with this name is not
defined on PortBindingLevel object. The easiest thing we can do to
resolve the discrepancy is adding the 'segment_id' UUID typed field to
PortBindingLevel, which is what the patch does. (An alternative could be
hacking our way around the lack of the field, building another layer of
complexity in the base OVO class for this special case; I figured it's
probably counterproductive, and we can live with 'segment_id' field even
though it's arguably somewhat redundant - 'segment' object field already
carries the ID.)
Adding a new field to PortBindingLevel object means that we need to bump
its version, as well as versions of all objects that use the newly
modified field type for their own fields. The only object that refers to
the type is Port. That's why we also bump the version of Port object.
To make older agents that use RPC callbacks work with the change, we
also provide corresponding obj_make_compatible methods for both Port and
PortBindingLevel objects.
Change-Id: I1ec56c57f87218520c2080c0b3450f1eabc13224
This reverts commit febeaf5d40.
This patch broke postgres tempest jobs, as well as introduced potential
race conditions in database layer because of mixed usage of old and new
engine facades.
Related-Bug: #1744829
Change-Id: Ic142ae7faf4e5f10cbdf761d7e6f3d442e94a3eb
This patch integrates Port Binding OVO in /plugins/ml2/db.py
and /plugins/ml2/plugin.py.
Co-Authored-By: Artur Korzeniewski <artur.korzeniewski@intel.com>
Change-Id: Idb76c0cb2a4d66690c9aca5ba338d5df814cd21e
Partially-Implements: blueprint adopt-oslo-versioned-objects-for-db
The neutron-lib commit I360545b6ee4291547e0c5c8e668ad03d3efa4725 moved
the externally consumed globals from neutron.common.constants into lib.
With the exception of PROVISIONAL_IPV6_PD_PREFIX all other constants
in neutron.common.constants should only be used in neutron, and will
hopefully remain that way. External consumers needing access to other
common constants should move them into lib first.
NeutronLibImpact
Change-Id: Ie4bcffccf626a6e1de84af01f3487feb825f8b65
All of the ML2 binding models were missing the revises_on_change
attribute to bump the revision of the port whenever they are
created/updated/deleted.
These are important because port binding happens in a separate
transaction so without them the revision number before and after
port binding was exactly the same. This opened up the L2 agent
to a race condition dependent on the order of processed push
notifications.
Closes-Bug: #1699034
Change-Id: I75f3c63941130ce845574e60214ac34e99111693
Neutron-lib 1.1.0 is now out and contains the portbindings
API definition (as per commit [1]). This patch moves neutron
references over to the neutron-lib version.
NeutronLibImpact
- Consumers using the public constants within neutron's
portbindings API extension must now use the values
from neutron-lib.
[1] 87e42f993c07ae320159d5123662ee9f3bd4d903
Change-Id: I669af9b4c712877772d91a03857ab108714001d4
This switches to the use of subqueries for 1-m relationships
which will result in a higher constant query factor but will
eliminate the potential for cross-product explosions.
Closes-Bug: #1649317
Change-Id: I6952c48236153a8e2f2f155375b70573ddc2cf0f
Extended the Primary Key of ml2_port_binding table to include "hosts"
and added a new column named "status" to indicate the status of the
port similar to the ml2_distributed_port_binding table. Updated the
PortBinding object with the above changes.
Change-Id: Ie01f83b01ab673b9ae7e05b4eaed504ffc8db773
Co-Authored-By: Brian Stajkowski <brian.stajkowski@rackspace.com>
Partial-Bug: #1580880
Those objects are intentionally not integrated into the database code so
far. This is to quicken access to their definitions to implement
push-notifications for security groups and ports.
The object embeds segmentation information in addition to what's
available through the model. Specifically, binding_levels field exposes
all ml2 binding levels, that from their side load corresponding network
segment object. The order for level objects in binding_levels list field
is guaranteed to be in the order of level. So the consumers can eg.
access the bottom binding info with:
port_obj.binding_levels[-1].segment
For PortBindingLevel object, we want to expose segmentation info. This
is achieved through a 'segment' ObjectField. The database model itself
contains segment_id too. There is no reason though to expose it for
Level object in two places (one as a model field, another one through
the ObjectField), so we avoid adding ID field. The base class that
handles loading for ObjectField based synthetic fields was assuming that
objects always have a field per model attribute, so it needed a slight
adjustment to support this case, where we extract foreign_keys
attributes from the model itself if the field is not present on the
object.
Partially-Implements: blueprint adopt-oslo-versioned-objects-for-db
Partially-Implements: blueprint push-notifications
Change-Id: I25de14e42e345d9235dbf4097c298ef5d606de51
Co-Authored-By: Martin Hickey <martin.hickey@ie.ibm.com>
Co-Authored-By: Rossella Sblendido <rsblendido@suse.com>
Co-Authored-By: Manjeet Singh Bhatia <manjeet.s.bhatia@intel.com>
Co-Authored-By: Brandon Logan <brandon.logan@rackspace.com>
Co-Authored-By: Victor Morales <victor.morales@intel.com>
Distributed port binding need to be implemented for HA router ports
to fix bug 1522980. HA ports can use existing DVR implementation for
multiple port binding. So we have to make current DVR port binding
implementation generic, so that all distributed ports(like DVR, HA)
can use it.
As part of making it generic, we rename 'ml2_dvr_port_bindings' table
to 'ml2_distributed_port_bindings', so that all distributed ports
(DVR, HA ..) can use this table.
Partial-Bug: #1595043
Partial-Bug: #1522980
Change-Id: I24650b7dee6305f801b457c4f21c8b16fb0eb6e0
Some standalone plugins, such as networking-ovn, are expecting
to store provider network information in neutron database, but
we have no table, like other extensions do, for provider
network extension defined.
This patch moves NetworkSegment table out of the ML2 code tree.
The API methods to operate segments are also moved, but stub
methods are still kept in the ml2 db API.
Co-Author: Miguel Lavalle <malavall@us.ibm.com>
Change-Id: I2c4f78fce591486ded63252af13fc0c60d02a3e8
Partially-Implements: blueprint routed-networks
uselist=False is used for one to one relationship, but for
DVRPortBinding, a router_interface_distributed port can have
multiple bindings. That causes SAWarning:
Multiple rows returned with uselist=False for lazily-loaded attribute
'Port.dvr_port_binding'.
"uselist=False" is misused in DVRPortBinding port relationship,
this patch will fix this.
Change-Id: I2b00d96aaa445e0977bc3d4957d35a28d44dd953
Closes-Bug: #1540259
I saw a patch set [1] that was running in to circular imports and
removing these. I thought it'd be better to remove them all in one
shot.
[1] https://review.openstack.org/#/c/261222/1/neutron/db/agents_db.py
Change-Id: If1a9ba3091ac99f01f73b98a7459358c3efd4dd5
To support hierarchical port binding, the driver and segment columns
are moved from the ml2_port_bindings and ml2_dvr_port_bindings tables
to a new ml2_port_binding_levels table. This new table can store
multiple levels of binding information for each port. It has the host
as part of its primary key so that it can be used for both normal and
DVR port bindings.
The cap_port_filter column is also removed from the
ml2_dvr_port_bindings table, since the adjacent driver and segment
columns are being moved, and this can trivially be done via the same
DB migration. It was included in the table by mistake and was never
used.
The logic required for hierarchical port binding will be implemented
in a dependent patch.
Gerrit Spec: https://review.openstack.org/#/c/139886/
Partially-implements: blueprint ml2-hierarchical-port-binding
Change-Id: I08ddc384763087fbac0fa3da3ed6e99b897df031
Description:
Currently, there is nothing in the schema that ensures segments
for a network are returned in the same order they were specified
when the network was created, or even in a deterministic order.
Solution:
We need to add another field named 'segment_index' in
'ml2_network_segment' table containing a numeric position index.
With segment_index field we can retrieve the segments in the
order in which user created.
This patch set also fixes ML2 invalid unit test case in
test_create_network_multiprovider().
Closes-Bug: #1224978
Closes-Bug: #1377346
Change-Id: I560c34c6fe1c5425469ccdf9b8b4905c123d496d
This commit builds on top of part 1 to introduce support for creating
dynamic network segments in ML2.
Change-Id: I399e1569baae6f24054aac15c4c51a2e44a20e5b
Partially implements: Blueprint ml2-type-driver-refactor
This patch introduces the models, the DB migrations
and the config options required by the L2 layer to
support DVR east/west traffic.
These changes will be used by the control-plane made
of ML2, L2pop and L2 agent.
Two new configuration options have been introduced:
'dvr_base_mac' is used to set DVR MAC addresses apart
from tenant ones (every distributed router will have
ports being created on compute hosts) and
'enable_distributed_routing' is used to enable dvr
support in the L2 agent. This gives the capability of
rolling out the dvr functionality in stages.
Partially-implements: blueprint neutron-ovs-dvr
DocImpact
Change-Id: Iab6505f239d2c4c9bcbf4e32a292d7b4b5320c8e
Authored-by: Vivekanandan Narasimhan <vivekanandan.narasimhan@hp.com>
Co-Authored-By: Armando Migliaccio <armamig@gmail.com>
In ml2 models parameter 'default' is used for vnic_type, profile and
vif_details, but in migrations 27cc183af192_ml2_vnic_type,
157a5d299379_ml2_binding_profile and
50d5ba354c23_ml2_binding_vif_details is used 'server_default' parameter.
Usage 'default' and 'server_default' should be equal in models and
migration. So models in models is added 'server_default' parameter.
Partial-bug: #1295539
Change-Id: If6a17f381d2550daf64916ad3c1b120f41406d56
The ML2 plugin stores the binding:profile port attribute, defined as a
dictionary, in its ml2_port_bindings DB table. Since the plugin can
support a variety of MechanismDrivers with different needs for
binding:profile attribute content, the plugin will accept, store, and
return arbitrary key/value pairs within the attribute. As with the
binding:host_id attribute, updates to binding:profile trigger
rebinding.
Implements: blueprint ml2-binding-profile
Change-Id: I01cba8d09dde9de1c6160d0235b0d289eed91b29
In addition to binding:vif_type, the neutron core plugin needs to
supply various information to nova's VIF driver, such as VIF security
details and PCI details when SR-IOV is being used. This information is
read-only, requires admin privileges, and is not intended for normal
users. Rather than add separate mechanisms throughout the stack for
each such requirement, the binding:capabilities port attibute, which
is a dictionary and is not currently not used by nova, is renamed to
binding:vif_details to serve as a general-purpose mechanism for
supplying binding-specific details to the VIF driver.
This patch does not remove or replace the CAP_PORT_FILTER boolean
previously used in binding:capabilities. A separate patch should
implement the specific key/value pairs carried by binding:vif_details
to implement VIF security. Another patch will implement the key/value
pairs needed for SR-IOV.
The ML2 plugin now allows the bound mechanism driver to supply the
binding:vif_details dictionary content, instead of just the
CAP_PORT_FILTER boolean previously carried by the binding:capabilities
attribute.
DocImpact: Need to update portbinding extension API, but no impact on
user or administrator documentation.
Implements: blueprint vif-details
Related-Bug: 1112912
Change-Id: I34be746fcfa73c70f72b4f9add8eff3ac88c723f
This patch adds support for requested vnic_type to be plugged to neutron port to ML2 plugin.
This patch contains:
1. New attribute 'binding:vnic_type' added to port binding extension.
Possible values are 'direct', 'macvtap' and 'normal'.
'binding:vnic_type' is allowed to be defined on port creation or changed
on port update by admin or tenant user.
'binding:vnic_type' can be also skipped in port defintion
2. Management of vnic_type by ML2 plugin, assuming default
vnic_type=normal
3. Add 'vnic_type' to ml2_port_bindings DB table
4. Add supported vnic_types for MechanismDrivers that are capable to bind
port.
5. Add DB migration script for ml2_vnic_type.
DocImpact: Need to update portbindings API docs and include in SR-IOV user docs
Change-Id: Ic88708fa9ece742f807c1d09bb49e499f99bd092
Implements: blueprint ml2-request-vnic-type
The ml2 plugin uses mechanism drivers to determine which network
segment and what VIF driver to use for a port. Mechanism drivers
supporting the openvswitch, linuxbridge, and hyperv agents are
added. The binding:host attribute is set on ports belonging to the
dhcp and l3 agents so that they can be bound.
To use with devstack until it is updated, set
"Q_ML2_PLUGIN_MECHANISM_DRIVERS=openvswitch,linuxbridge" in localrc.
The hyperv L2 agent does not currently implement the agents_db RPC,
and will therefore not work with its ml2 mechanism driver. This issue
will be tracked as a bug to be fixed in a separate merge.
implements blueprint: ml2-portbinding
Change-Id: Icb9c70d8b0d7fcb34b57adc760bb713b740e5dad
This change renames everything to Neutron while providing backwards
compatible adjustments for Grizzly configuration files.
implements blueprint: remove-use-of-quantum
Change-Id: Ie7d07ba7c89857e13d4ddc8f0e9b68de020a3d19
Rodolfo Alonso