← Back to team overview

openstack team mailing list archive

Re: Network Service for L2/L3 Network Infrastructure blueprint

 

Hello,

We, NTT DATA, also agree with majority of folks.
It's realistic shooting for the the Diablo time frame to have
the new network service.

Here are my suggestions:

 - I know that there were several documents on the new network service issue
   that were locally exchanged so far.
   Why not collecting them into one place and share them publicly?

 - I know that the discussion went into a bit implementation details.
   But now, what about starting the discussion from the higher level
   design things (again)?  Especially, from the requirements level.

Any thoughts?

Masanori


From: John Purrier <john@xxxxxxxxxxxxx>
Subject: Re: [Openstack] Network Service for L2/L3 Network Infrastructure blueprint
Date: Sat, 29 Jan 2011 06:06:26 +0900

> You are correct, the networking service will be more complex than the volume
> service. The existing blueprint is pretty comprehensive, not only
> encompassing the functionality that exists in today's network service in
> Nova, but also forward looking functionality around flexible
> networking/openvswitch and layer 2 network bridging between cloud
> deployments.
> 
> This will be a longer term project and will serve as the bedrock for many
> future OpenStack capabilities.
> 
> John
> 
> -----Original Message-----
> From: openstack-bounces+john=openstack.org@xxxxxxxxxxxxxxxxxxx
> [mailto:openstack-bounces+john=openstack.org@xxxxxxxxxxxxxxxxxxx] On Behalf
> Of Thierry Carrez
> Sent: Friday, January 28, 2011 1:52 PM
> To: openstack@xxxxxxxxxxxxxxxxxxx
> Subject: Re: [Openstack] Network Service for L2/L3 Network Infrastructure
> blueprint
> 
> John Purrier wrote:
> > Here is the suggestion. It is clear from the response on the list that
> refactoring Nova in the Cactus timeframe will be too risky, particularly as
> we are focusing Cactus on Stability, Reliability, and Deployability (along
> with a complete OpenStack API). For Cactus we should leave the network and
> volume services alone in Nova to minimize destabilizing the code base. In
> parallel, we can initiate the Network and Volume Service projects in
> Launchpad and allow the teams that form around these efforts to move in
> parallel, perhaps seeding their projects from the existing Nova code.
> > 
> > Once we complete Cactus we can have discussions at the Diablo DS about
> progress these efforts have made and how best to move forward with Nova
> integration and determine release targets.
> 
> I agree that there is value in starting the proof-of-concept work around
> the network services, without sacrificing too many developers to it, so
> that a good plan can be presented and discussed at the Diablo Summit.
> 
> If volume sounds relatively simple to me, network sounds significantly
> more complex (just looking at the code ,network manager code is
> currently used both by nova-compute and nova-network to modify the local
> networking stack, so it's more than just handing out IP addresses
> through an API).
> 
> Cheers,
> 
> -- 
> Thierry Carrez (ttx)
> Release Manager, OpenStack
> 
> _______________________________________________
> Mailing list: https://launchpad.net/~openstack
> Post to     : openstack@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~openstack
> More help   : https://help.launchpad.net/ListHelp
> 
> 
> _______________________________________________
> Mailing list: https://launchpad.net/~openstack
> Post to     : openstack@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~openstack
> More help   : https://help.launchpad.net/ListHelp



Follow ups

References