Thank you for review. Okay, the approach (distinct plugins + OVS-related library) sounds quite reasonable. So let's delay it to E-4 (or F). And I'll give the refactoring a try.
BTW, I need a small twist to nova/network. Is it acceptable for you? I think it's harmless. https://review.openstack.org/#change,3175 thanks, On Thu, Jan 19, 2012 at 01:21:33AM -0800, Dan Wendlandt wrote: > Thanks Isaku. > > We chatted about this briefly at the netstack meeting on Tuesday. The > feeling was that the Ryu controller should probably be its own Quantum > plugin, in its own directory in the Quantum source. Even though both > plugins use open vswitch, their mode of operation actually seems quite > different (OVS plugin configures OVS locally without a controller, > while the Ryu plugin uses a OpenFlow controller). As the code bases > for both plugins grow, it is like that the set of supported features, > and the corresponding source code, configuration, documentation, etc. > will continue to diverge, leading to confusion for developers and > users if we do not split them out. > > That said, there definitely is some overlap in functionality. In > general, the goal for Quantum plugins is that code that is useful to > many plugins can be pulled into shared libraries, so that multiple > plugins can use it. I see two clear areas for doing so in this case: > > - taking some of the generic logic for getting/fetching nets + ports > from the SQLAlchemy datastore that is in the OVS quantum plugin and > putting it in a more generic QuantumPluginSqlAlchemy class, so it can > be leveraged by multiple plugins. Plugins that want to use the > SQLAlchemy datastore could just sub-class this base class. I would > imagine that the base class would create 'listener' methods (e.g., > on_network_create(network)) that a sub-class could implement if they > had special customization behavior to do whenever an particular event > happened (this is fairly similar to what your patch already did so > that the VLANMap logic was only invoked if using the OVS plugin, not > the Ryu plugin). > > - creating a shared library for some of the common OVS related agent > functionality (including manipulating the OVS integration bridge). > Creating a library will make it a bit more cumbersome to use the > agent, as there will be multiple agent files to copy over the > hypervisor, but we really need to get the agent packaged anyway, at > which point that concern should go away. > > Doing this kind of a refactoring is almost certainly too much to try > to squeeze into E-3, but it should certainly be possible to do in E-4. > Thanks, > > Dan > > > > On Sat, Jan 14, 2012 at 7:42 PM, Isaku Yamahata <yamah...@valinux.co.jp> > wrote: > > I requested the review at > > https://review.openstack.org/3055 > > > > If it's too late for Esses-3, please let me know. > > > > thanks in advance > > > > On Wed, Jan 11, 2012 at 04:55:14PM +0900, Isaku Yamahata wrote: > >> On Wed, Jan 11, 2012 at 11:15:03AM +0900, Isaku Yamahata wrote: > >> > > Also, thank you for registering a blueprint. ?To get the code merged > >> > > into > >> > > Quantum, you will need to propose a diff for review following the > >> > > standard > >> > > OpenStack development process (see: > >> > > http://wiki.openstack.org/GerritWorkflow). > >> > > > >> > > > >> > > Given that this looks like a pretty big patch, you should do this very > >> > > soon if > >> > > you would like this to be part of the Essex-3 release (code freeze > >> > > date is two > >> > > weeks away, but big patches ?from someone new to the project should be > >> > > proposed > >> > > well in advance of the code freeze to make sure all review comments > >> > > can be > >> > > addressed). ?Otherwise, we should be able to get this in during the > >> > > Essex-4 > >> > > cycle, so it will still make the main Essex release. ?Please do me a > >> > > favor and > >> > > update the blueprint indicating whether you are planning on working on > >> > > this for > >> > > Essex-3. > >> > > >> > I delayed it to Essex-4 as the patch needs clean up and improvement. > >> > So I think it would be difficult to make it at Essex-3. > >> > >> After consideration a bit, let me try to make it for Essex-3. > >> -- > >> yamahata > >> > >> -- > >> Mailing list: https://launchpad.net/~netstack > >> Post to ? ? : netstack@lists.launchpad.net > >> Unsubscribe : https://launchpad.net/~netstack > >> More help ? : https://help.launchpad.net/ListHelp > >> > > > > -- > > yamahata > > > > -- > ~~~~~~~~~~~~~~~~~~~~~~~~~~~ > Dan Wendlandt > Nicira Networks:?www.nicira.com > twitter: danwendlandt > ~~~~~~~~~~~~~~~~~~~~~~~~~~~ > -- yamahata -- Mailing list: https://launchpad.net/~netstack Post to : netstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~netstack More help : https://help.launchpad.net/ListHelp
