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.
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. Andre On Sun, Jun 16, 2013 at 2:30 PM, Zang MingJie <[email protected]> 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 <[email protected]> > 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 <[email protected]> > > 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 <[email protected]> > >> 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 > > [email protected] > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > > > _______________________________________________ > OpenStack-dev mailing list > [email protected] > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >
_______________________________________________ OpenStack-dev mailing list [email protected] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
