openstack team mailing list archive

[Isaku Yamahata <yamahata@xxxxxxxxxxxxx>]

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