Open Stack

Please see the inline. 


Mar 5, 2013, 5:58 AM, Jay Pipes <jaypipes at gmail.com> 작성:

> 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.


+1 here. 
I have to agree that this last one is the most needed in our case as well. 
After realizing this "simulated multi-host with colocated mode" is not included in grizzly, I would be highly interested in actively participating in any effort on making the last one possible (multi-host like l3 + dhcp model). 
(BTW, this is Jay Ahn from Korea Telecom) 


> 
>> 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
> 
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev