Open Stack

Hi all,

As promised at the ml2 kickoff meeting last week, attached is our basic
proposal for the ml2 mechanism driver API. Sorry for the delay in getting
this out. We'll be on the meeting tomorrow morning and can also discuss
some of these points then. Assuming we agree on the direction, we'll
implement the backend calls from ml2 plugin and get this posted for review.

Our original proposal along these lines within the OVS Plugin (as described
in https://blueprints.launchpad.net/quantum/+spec/ovsplugin-hardware-devices)
defined a pretty specific set of methods based on our needs at the physical
infrastructure layer (plug_host, unplug_host) that were called based on the
parameters passed into the various quantum plugin methods (for example, if
create_port is called as part of booting the VM, then call plug_host,
otherwise don't).

After getting more familiar with the ml2 plugin code and looking at some of
the other blueprints that are looking to make use of the MechanismDriver,
we've instead gone with a more simple passthrough model using the existing
plugin language of create_network / update_network / delete_network /
create_port / update_port / delete_port. This makes ml2 a bit more of a
"meta-plugin" on top of the various mechanism drivers, but ultimately the
information passed to the mechanism driver really needs to be the same as
what is passed to the associated ml2 plugin call, just filled in with more
information by ml2 and the type drivers along the way. The main reason I
don't love using the same names is that it doesn't really help enforce the
distinction between plugins, type drivers, and mechanism drivers... but we
also failed at coming up with a distinct yet equally generic set of names
:). We wanted to ensure that we could handle other people's use cases and
not just our own, so passing in the full dict defining the network or port
seemed like an easy way to do this compared to what we had originally
proposed. If people would rather see distinct names compared to the plugin
and/or more restrictive and explicit parameters, that'd be fine with us too
and we appreciate suggestions.

One related change that may be of interest to others is
https://review.openstack.org/#/c/29767/, which adds the hostname to the
port binding calls. We're also interested in getting the VM id / name
passed through as well in the port bindings. Bob, not sure how this fits in
with your modular l2 port binding blueprint (
https://blueprints.launchpad.net/quantum/+spec/ml2-portbinding).

One question we'd love to get feedback on - for our use case, we're only
going to make use of calls made within the transaction context (ie they
don't block and they cause a rollback on failure). Not having a good use
case for a mechanism driver call made outside the transaction context, we
haven't added any apis for this (how they're planning to be used would help
me name them). Anyone have any use cases for this?

Appreciate everyone's feedback. Bob, is this down the path you were
thinking?

Getting the backend code hooked up to make these calls in the ml2 plugin is
pretty trivial, so once this is settled we can have that posted for review
pretty quickly.

Thanks
Andre and Sukhdev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20130612/163de088/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: driver_api.py
Type: application/octet-stream
Size: 8439 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20130612/163de088/attachment.obj>