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
