Open Stack

On Jun 16, 2013, at 5:32 PM, Andre Pech <apech at aristanetworks.com> wrote:
> 
> Hi Zang,
> 
> As Sukhdev mentioned, we have an Arista mechanism driver in the works that covers the physical network orchestration case, and we'll send that out for review as soon as it's ready. I believe that Kyle Mestery is going to add a mechanism driver for OpenDaylight to cover the external SDN controller case.
> 
Yes, we have an OpenDaylight plugin about 80% done, but the plan is to migrate it to an ML2 MechanismDriver and make it the Open Source controller example for ML2. Now that the base MechanismDriver code is out, I plan to start on this work soon and hope to have something posted in the next week.

> I think the ultimate plan is to move the logic for propagating changes to the associated compute node agents (as needed for linuxbridge/openvswitch) to mechanism drivers as well. Since the logic is working fine as is, I've been putting that off until it's truly necessary.
> 
Agreed, because in the case of controller plugins, we won't want the default code to run, as the controller will handle things.

Thanks,
Kyle

> Andre
> 
> 
> 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
> >
> 
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev