Open Stack

Hi all,

I've posted an initial implementation of the ml2 mechanism driver for
review at  https://review.openstack.org/33201. It should be in good enough
shape for others to start implementing their own mechanism drivers, though
the API is obviously still a work-in-progress and subject to change before
the Havana release. Appreciate people's review.

Thanks
Andre


On Wed, Jun 12, 2013 at 11:15 AM, Andre Pech <apech at aristanetworks.com>wrote:

> Hi all,
>
> Wanted to send an updated proposal based on the discussions at this
> morning's ml2 meeting. Thanks everyone for the feedback.
>
> Main difference is the definitions of call that happen both within the
> transaction context and afterwards. Kyle had proposed the naming of
> appending _tx to the methods that happen within the transaction. After
> thinking about it a bit more, I ended up going with _db instead (probably
> the networking guy in me substituting tx with transmit :)). This is under
> the assumption that calls made within the transaction context are really to
> allocate resources within the database (there's not much else they can do
> given that these calls aren't supposed to block), while the non _db calls
> can then push whatever information is necessary to the outside controller /
> hardware devices, etc. Appreciate feedback on the naming.
>
> Please see attached for the updated proposal. Feedback appreciated. I'll
> be working on getting these calls hooked into the ml2 plugin and will work
> to send out a review this weekend.
>
> Andre
>
>
> On Wed, Jun 12, 2013 at 12:25 AM, Andre Pech <apech at aristanetworks.com>wrote:
>
>> 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/20130616/86579828/attachment.html>