On Thu, Jan 19, 2012 at 2:25 AM, Isaku Yamahata <yamah...@valinux.co.jp> wrote: > 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.
Great. > > 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 Yes, that looks reasonable. I +1'd the change, though since it is in nova we will need reviews from nova core developers as well. Dan > > 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 -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~ Dan Wendlandt Nicira Networks: www.nicira.com twitter: danwendlandt ~~~~~~~~~~~~~~~~~~~~~~~~~~~ -- Mailing list: https://launchpad.net/~netstack Post to : netstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~netstack More help : https://help.launchpad.net/ListHelp
