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 -- Mailing list: https://launchpad.net/~netstack Post to : netstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~netstack More help : https://help.launchpad.net/ListHelp
