Open Stack

On Mon, Mar 4, 2013 at 8:00 AM, Jay Pipes <jaypipes at gmail.com> wrote:

> On Mon, Mar 4, 2013 at 10:47 AM, Russell Bryant <rbryant at redhat.com>wrote:
>
>> One area that I
>> think could use some additional attention is the collaboration between
>> Nova and Quantum.  I would like to step up the effort to get to where we
>> are no longer maintaining two networking stacks.
>>
>
> +10
>
> 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

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.

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.


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.

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

Dan




>
>
> -jay
>
> p.s. The above comment in no way is a slight on VIsh or Dan W. I
> understand the decisions that have been made regarding feature
> enhancements, I just think it's time for some housekeeping to be done.
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>


-- 
~~~~~~~~~~~~~~~~~~~~~~~~~~~
Dan Wendlandt
Nicira, Inc: www.nicira.com
twitter: danwendlandt
~~~~~~~~~~~~~~~~~~~~~~~~~~~
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20130304/b4bc6ef5/attachment.html>