Open Stack

On 03/04/2013 01:19 PM, Dan Wendlandt wrote:
> On Mon, Mar 4, 2013 at 8:00 AM, Jay Pipes <jaypipes at gmail.com
>     Instead of focusing on the ability to entirely replace internal Nova
>     networking with Quantum, unfortunately feature development in
>     Quantum has been the focus over the last two release cycles.
> 
> I'm actually surprised to hear this comment.  If you look at the 'high'
> or 'critical' features for quantum in folsom or grizzly, reaching full
> parity with nova use cases has been the highest priority. 
> 
> Nova Parity In Folsom: 
> - IPAM
> - L3 + floating IPs
> - basic metadata 
> 
> Nova Parity In Grizzly: 
> - security groups 
> - better metadata integration
> - multi-host like L3 + dhcp model

This last one is the most needed, IMHO. Without a migration path from
multi-host VLAN to software-defined networking in Quantum, we are stuck
using nova-network and nova-manage network create.

> The only thing I see as missing is a cloudpipe VPN equivalent, and to be
> honest the reason for this is that no one seems very interested in using
> this capability. It was targeted for Folsom, but no one showed up to
> write any code.  I've heard a few people coordinating on plans for
> Havana for VPN, so achieving it seems more likely.

We don't use Cloudpipe, sorry.

> Are there other key gaps you see?  When I had talked with Vish about
> this in the past, the model was to freeze nova-network to allow Quantum
> to reach parity, and then push people away from nova-network toward
> Quantum.

I haven't noticed such a freeze. AFAIK, there was lots of work done in
Grizzly timeframe to add networking management API calls to Nova to
remove the need to use nova-manage for a lot of stuff, which would be a
welcome improvement, but unless I am badly mistaken, this work was in
contradiction to any freeze on nova-network. Vish, please correct me if
I am wrong.

>     What this has brought is a whole bunch of new plugins and drivers as
>     all the networking hardware companies attempt to get in on the game,
>     but unfortunately, it's caused serious stability and long-term
>     architecture problems, IMO.
> 
> I agree there has been a flood of new plugins from different companies.
>  In almost all cases, this comes from new contributors, and it not
> consuming core team resources other than reviews.  Turning these new
> contributors away does not strike me as feasible in an open community
> like OpenStack. To maintain balance, we've been stringent about making
> sure that new plugins are always ranked as lower priority for review
> cycles than core community efforts like the items I outlined above.

I wasn't suggesting turning new contributors away, far from it. I can
definitely see the value of all the new drivers/plugins, and I
appreciate you telling me that core reviewer time isn't prioritized on
such things.

> We're definitely open to suggestions on how we can improve the process
> though :)

Meh, who knows, maybe I'm just in a particularly bitchy mood of late,
having to deal with so many niggly little deployment issues in Chef,
Keystone, humans, etc. Sorry for the noise.

-jay