openstack team mailing list archive

[Masanori ITOH <itoumsn@xxxxxxxxxxxxx>]

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