Open Stack

Hi Andre:

will there be any example implementation to show what and how does it
work ? A smallest functional prototype with only local or flat network
support will help a lot

Thanks

On Mon, Jun 17, 2013 at 5:08 AM, Andre Pech <apech at aristanetworks.com> wrote:
> 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
>>
>>
>
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>