Open Stack

Yes, we are working on putting together Arista Driver based upon this API.
 As soon as it is ready, we will post it for review as well as others to
use as an example.

regards..
-Sukhdev



On Sun, Jun 16, 2013 at 2:30 PM, Zang MingJie <zealot0630 at gmail.com> wrote:

> 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
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20130616/5723dd8e/attachment.html>