On Tue, Jan 10, 2012 at 09:13:33AM -0800, Dan Wendlandt wrote: > [ narrowing scope to netstack list, as there are more design discussion ] > > Hi Yamahata,
Hi. > Since Essex-3 is now near, I wanted to touch based with you again about this. > > With respect to your thoughts below about "driver-specific" configuration. I > think it is fine for your code to store configuration in the DB, if you > prefer. > It is also possible to have different versions of the OVS plugin use > different > versions of the ini file. Either way, I think the goal of avoiding a single > global conf file with many driver-specific configuration options is avoided. Thank you for the comment. So it is agreed that the basic direction is okay. > 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. > Thanks, > > Dan > > > On Sun, Dec 11, 2011 at 6:32 PM, Isaku Yamahata <yamah...@valinux.co.jp> > wrote: > > On Fri, Dec 09, 2011 at 09:02:09AM -0800, Dan Wendlandt wrote: > > Oh, definitely. I really should have set "create a blueprint and target > it as > > essex-3 as a place-holder". We'll definitely need to talk through the > design > > first (though we probably don't need to flood the entire OS community > with such > > detailed discussions, so we can move it to the netstack list). > > > > > > > > - introduce OVS driver/OVS agent driver > > I think, there can be several kind of openflow controllers, so this > is > > reasonable. > > The code refactoring and new options would be easily merged, I > hope. > > > > > > I haven't looked at the entire patch yet, but yes, we'll have to figure > out how > > to handle different capabilities in the agent. I know of others doing > similar > > things, so coming up with a pattern for this will be valuable. > > I registered the blueprint. > https://blueprints.launchpad.net/quantum/+spec/ovs-driver-extension > > Other discussion point is how to pass driver-specific parameters to OVS > agent. > > passing parameters to OVS agent > The current implementation uses ovs_quantum_plugin.ini on each > compute-node. > Maybe there are several options. My preference is the option B. > > A. All parameters in ovs_quantum_plugin.ini for ovs agent > Each ovs_quantum_plugin.ini in compute-node has all necessary > parameters. > The administrator must guarantee all of them are consistent. > > B. ovs_quantum_plugin.ini in quantum server. > ovs_quantum_plugin.ini for ovs agent only have [DATABASE] section and > OVS:integration-bridge. > Other options which would be commont to drivers or specific to each > driver > are passed to quantum-server, and stored in DB table. > Each agent get those parameters from DB > > C. Other ideas > > > thanks, > -- > 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
