[openstack-dev] Nova PTL Candidacy
Jay Pipes
jaypipes at gmail.com
Mon Mar 4 20:58:25 UTC 2013
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
More information about the OpenStack-dev
mailing list