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
