Many neutron extensions(like portsecurity) use the plugin_context
variable instead of just the database session. This change
modifies the extension driver api to pass the plugin_context
Change request also modifies the extend_XXX resource api to use the
respective data model(network/subnet/port) passed to it.
Implements: blueprint extensions-in-ml2
Partially Implements: blueprint ml2-ovs-portsecurity
Closes-Bug: 1382448
Change-Id: Icf84615e5fee8b59cbc95ab9b634f1a49f4b56a3
The following ML2 driver API changes are required to support
hierarchical port binding:
* Add segments_to_bind PortContext property containing the list of
network segments with which a mechanism driver should try to bind
the port. All mechanism drivers that bind ports should now use this
property in place of network.network_segments, which contains only
the network's static segments.
* Replace several PortContext properties (bound_segment, bound_driver,
original_bound_segment, original_bound_driver) with new properties
(binding_levels, top_bound_segment, bottom_bound_segment,
original_binding_levels, original_top_bound_segment,
original_bottom_bound_segment) in order to represent hierarchical
bindings.
* Add stubbed-out continue_binding() method to PortContext, allowing
mechanism drivers to partially bind the port.
All existing drivers and unit tests are updated accordingly.
The DB schema changes and logic required for hierarchical port binding
will be implemented in dependent patches.
Gerrit Spec: https://review.openstack.org/#/c/139886/
Partially-implements: blueprint ml2-hierarchical-port-binding
Change-Id: Icb1a016f4661e427cb6cfa3452802ba5e64b7124
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
The current ML2 plugin supports only extensions defined in the plugin and it
does not support any extensions in the mechanism drivers. The changes in this
commit allows mechanism drivers to define new extensions.
Change-Id: I28da19fabf6de2e9f0d687f875aaaa24c8bbc4f0
Implements: blueprint extensions-in-ml2
Bindings to host or status may need further encapsulation
to avoid exposing mechanism drivers to underlying DB model
details. This was particularly true in the case of the
l2pop mech driver.
As a result, some docstrings were reworded, and the newly
introduced properties used directly in the mech drivers.
Partially-implements: blueprint neutron-ovs-dvr
Supports blueprint: ml2-hierarchical-port-binding
Change-Id: If2a373ef04d19b164585fb4bde4fe6e0cfaf43be
ML2 provider network partial specs let admins choose some
multiprovider network attributes and let neutron choose remaining
attributes. This change provides the implementation for
multiprovider networks.
In practice, for VLAN/GRE/VXLAN segments provider:segmentation_id
choice can be delegated to neutron, in such case neutron try to find
a segment in tenant network pools which respects provided segment
attributes. For VLAN segments provider:physical_network choice can
also be delegated.
DocImpact
Implements blueprint provider-network-partial-specs
Change-Id: I1cf1441a179ec527674276b71e9924841f8570b6
ML2 provider networks partial specs let admins choose some provider
network attributes and let neutron choose remaining attributes. This
change provides the implementation for VLAN provider networks.
In practice, for VLAN provider networks provider:physical_network
and provider:segmentation_id choices can be delegated to neutron,
in such case neutron will try to find a network in tenant network
pools which respects provided provider attributes.
DocImpact
Related to blueprint provider-network-partial-specs
Partial-Bug: #1330562
Change-Id: I2c52c71167edaa153b2e04681273e2f1be8d03aa
The ML2 plugin now calls the bind_port() operation on the registered
mechanism drivers outside of any enclosing DB transaction. Ports are
created or updated in one transaction, then a binding is established
if possible, and finally a second transaction commits the binding
result.
With [re]binding moved outside the DB transaction that triggered it,
it is now possible that multiple threads or processes will
concurrently try to bind the same port, or that the port will be
updated between transactions. Concurrent attempts to bind the same
port are allowed to proceed, which results are used is resolved in the
second transaction, and binding is retried if necessary.
Improvements to the Cisco Nexus driver and unit tests from Rich Curran
needed due to the binding changes are also included.
Closes-Bug: 1276391
Closes-Bug: 1335226
Change-Id: I65dafc330d6e812dad0667d2383858504d0ba299
The OpenDaylight mechanism driver does not depend on an L2 agent to
plug the port. Now that nova waits for notification that the port
status is ACTIVE, the ML2 driver API is extended so that the mechanism
driver that binds a port can optionally set the port status, and the
OpenDaylight mechanism driver uses this to set the port status to
ACTIVE.
Closes-Bug: 1301449
Change-Id: I171c405f36b4f2354d9585e8ae3dfa50ddaa9a7e
This commit enables the H301 hacking rule by removing all the
multiple imports in a single line from neutron.
Partial-Bug: #1291032
Change-Id: I7ba7f82fb36a433d73190eb3d568b6961ccb57c6
The API implemented by ML2 mechanism drivers included three methods
related to port binding that were called within DB transactions, but
that could potentially involve communication with controllers or
devices that should not be done within transactions. A subsequent
patch will move the calls to bind_port() outside of tranactions. This
patch eliminates the other two methods from the MechanismDriver API.
The validate_port_binding() method was previously called on the bound
mechanism driver to check whether an existing binding was still valid,
so that the port could be rebound if something changed. But since nova
has no way to handle changes to binding:vif_type or
binding:vif_details after a port is initially plugged, this turned out
not to be useful, so the method has been removed from the
MechanismDriver API. Now, once a port is successfully bound, the
binding remains until the port is deleted or any of it's
binding:host_id, binding:vnic_type, or binding:profile attribute
values are changed.
The unbind_port() method was previously called on the bound mechanism
driver as an existing binding was removed. This method was not used by
any existing mechanism drivers, and was redundant with the
update_port_precommit() and update_port_postcommit() methods that are
called on all mechanism drivers when an existing binding is removed,
so this method has also been removed from the driver API.
Eliminating the unbind_port() call allows the binding details to be
made available via the PortContext in delete_port_postcommit() calls,
completing the resolution of bug 1276395.
Closes-bug: 1276395
Partial-bug: 1276391
Change-Id: I70fb65b478373c4f07f5273baa097fc50e5ba2ef
The following properties are added to the PortContext object passed to
ML2 mechanism drivers for port operations:
* bound_driver - name of current bound driver
* original_bound_driver - name previously bound driver in an update
* original_bound_segment - network segment used in previous binding
Some issues with the existing ML2 port binding unit tests were also
fixed.
The remainder of the fix for bug 1276395, making these binding details
available to mechanism drivers when a port is deleted, will be
addressed as part of the fix for bug 1276391.
Partial-Bug: #1276395
Change-Id: I9ecff4a4e044920ed2dde709c89aeb9bc773220d
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
__metaclass__ cannot be used in python3.
six be used in general for python 3 compatibility.
Change-Id: Ib0d71b9676dc01390679396443575c05975d3b58
Closes-Bug: #1236648
Fixes two comment lines regarding when bind_port
is called. The correct comment should indicate that
bind_port is called prior to "create_port_precommit or
update_port_precommit" rather than
"create_network_precommit or update_network_precommit".
Change-Id: I5c0cb49efb43b15fdc5a7f88569e19fcf8d72819
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
there was a copy/paste error in GRE/VXlan type drivers implementation.
the segment wasn't returned while validating the provider network.
Change-Id: I7df6d2e714d09618644f935a9ed41354b62de9d0
Fixes: bug #1202244
Define the Mechanism Driver interface for create/update/delete
operations on networks and ports. For each of these event, the
Mechanism Driver provides one method that is called within the
database transaction of the ml2 plugin method, and one that is called
after the transaction is completed.
Support for mechanism drivers is still a work-in-progress, and the
interface is subject to change in future versions before the release
of Havana. However this initial version should be sufficient to enable
others to start defining their own mechanism drivers.
Change-Id: Ife30215589792ee27df9897d3b2bc04392638266
Implements: blueprint ml2-mechanism-drivers
Fixes: bug #1199977
Fixes: bug #1199978
DocImpact
This change renames everything to Neutron while providing backwards
compatible adjustments for Grizzly configuration files.
implements blueprint: remove-use-of-quantum
Change-Id: Ie7d07ba7c89857e13d4ddc8f0e9b68de020a3d19
Shweta P