[ narrowing scope to netstack list, as there are more design discussion ] Hi Yamahata,
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. 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. 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 ~~~~~~~~~~~~~~~~~~~~~~~~~~~
-- Mailing list: https://launchpad.net/~netstack Post to : netstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~netstack More help : https://help.launchpad.net/ListHelp
