Open Stack

On Sun, Aug 12, 2012 at 03:31:10PM -0700, Dan Wendlandt wrote:

>     [Agent or VIFDriver]
>     This plugin has an agent that corrects only port information. Another
>     solution is plugin-specific VIFDriver/InterfaceDriver that
>     plugs interface, gets port information and sends it to Quantum Server.
>     The reason why I modified agent: there are some discussions about plugging
>     a network interface around F summit.  1. Plugin specific
>     codes should be separate from nova.  2. VIFDriver should be focused on only
>     plugging (work something required to plug: e.g..
>     VIFDriver for Cisco plugin finds which device to plug).
>     But, Ryu plugin has plugin-specific VIFDriver(and InterfaceDriver) that
>     plugs VIF and corrects port information. It is similar to
>     NEC Plugin's VIFDriver for Essex.  Is this acceptable?
>     Or, plugin developer can choice it with considering trade-off between code
>     separation and behavior simplification.
> 
> 
> The Ryu vif-driver is in the Quantum repo, which in general is bad and has led
> to breakage as things change in Nova, and the vif-driver that is not in nova
> gets out of date.  Thus, I'd rather arrive at a model where all vif-drivers are
> in Nova.  

Right now I'm addressing elimination of Ryu specific vif driver by replacing
OVS's with iface-id in ovsdb.


> What we want to avoid is complex and frequently changing logic in the Nova
> vif-plugging.  What would be nice to arrive at is if we could get a common
> model used by many plugins to report information from the vif-plugging back to
> Quantum.  With that, Quantum would have a way of providing data to Nova (i.e.,
> the data returned by the port create request) and Nova would have the ability
> to report any data resulting from the plug back to Quantum.  Between the two, I
> think we should have most bases covered.  This founds like a good topic for the
> Grizzly summit.  I'll add it to my list of topics to suggest :) 

Yes, this will be very useful.
-- 
yamahata