openstack team mailing list archive

["John Purrier" <john@xxxxxxxxxxxxx>]

Thanks for the response, Andy. I think we actually agree on this J.

 

You said:

 

This statement is invalid, nova is already broken into services, each of which can be dealt with individually and scaled as such, whether the code is part of the same repository has little bearing on that. The goals of scaling are orthogonal to the location of the code and are much more related to separation of concerns in the code, making sure that volume code does not rely on compute code for example (which at this point it doesn't particularly).

 

The fact that the volume code and the compute code are not coupled make the separation easy. One factor that I did not mention is that each service will present public, management, and optional extension APIs, allowing each service to be deployed independently.

 

You said:

 

That suggestion is contradictory, first you say not to separate then you suggest creating separate projects. I am against creating separate projects, the development is part of Nova until at least Cactus.

 

This is exactly my suggestion below. Keep Nova monolithic until Cactus, then integrate the new services once Cactus is shipped. There is work to be done to create the service frameworks, API engines, extension mechanisms, and porting the existing functionality. All of this can be done in parallel to the stability work being done in the Nova code base. As far as I know there are not major updates coming in either the volume or network management code for this milestone.

 

John

 

From: Andy Smith [mailto:andyster@xxxxxxxxx] 
Sent: Friday, January 28, 2011 12:45 PM
To: John Purrier
Cc: Rick Clark; Jay Pipes; Ewan Mellor; Søren Hansen; openstack@xxxxxxxxxxxxxxxxxxx
Subject: Re: [Openstack] Network Service for L2/L3 Network Infrastructure blueprint

 

 

On Fri, Jan 28, 2011 at 10:18 AM, John Purrier <john@xxxxxxxxxxxxx> wrote:

Some clarification and a suggestion regarding Nova and the two new proposed services (Network/Volume).

To be clear, Nova today contains both volume and network services. We can specify, attach, and manage block devices and also specify network related items, such as IP assignment and VLAN creation. I have heard there is some confusion on this, since we started talking about creating OpenStack services around these areas that will be separate from the cloud controller (Nova).

The driving factors to consider creating independent services for VM, Images, Network, and Volumes are 1) To allow deployment scenarios that may be scoped to a single service, so that we don't drag all of the Nova code in if we just want to deploy virtual volumes, and 2) To allow greater innovation and community contribution to the individual services.

Another nice effect of separation of services is that each service can scale horizontally per the demands of the deployment, independent of the other services.

 

This statement is invalid, nova is already broken into services, each of which can be dealt with individually and scaled as such, whether the code is part of the same repository has little bearing on that. The goals of scaling are orthogonal to the location of the code and are much more related to separation of concerns in the code, making sure that volume code does not rely on compute code for example (which at this point it doesn't particularly).

 


We have an existing blueprint discussing the Network Service. We have *not* published a blueprint discussing the Volume Service, this will be coming soon.

The net is that creating the correct architecture in OpenStack Compute (automation and infrastructure) is a good thing as we look to the future evolution of the project.

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.

 

That suggestion is contradictory, first you say not to separate then you suggest creating separate projects. I am against creating separate projects, the development is part of Nova until at least Cactus.

 

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.

Thoughts?

John


-----Original Message-----
From: openstack-bounces+john=openstack.org@xxxxxxxxxxxxxxxxxxx [mailto:openstack-bounces+john <mailto:openstack-bounces%2Bjohn> =openstack.org@xxxxxxxxxxxxxxxxxxx] On Behalf Of Rick Clark
Sent: Friday, January 28, 2011 9:06 AM
To: Jay Pipes
Cc: Ewan Mellor; Søren Hansen; openstack@xxxxxxxxxxxxxxxxxxx
Subject: Re: [Openstack] Network Service for L2/L3 Network Infrastructure blueprint

On 01/28/2011 08:55 AM, Jay Pipes wrote:
> On Fri, Jan 28, 2011 at 8:47 AM, Rick Clark <rick@xxxxxxxxxxxxx> wrote:
> I recognise the desire to do this for Cactus, but I feel that pulling
> out the network controller (and/or volume controller) into their own
> separate OpenStack subprojects is not a good idea for Cactus.  Looking
> at the (dozens of) blueprints slated for Cactus, doing this kind of
> major rework will mean that most (if not all) of those blueprints will
> have to be delayed while this pulling out of code occurs. This will
> definitely jeopardise the Cactus release.
>
> My vote is to delay this at a minimum to the Diablo release.
>
> And, for the record, I haven't seen any blueprints for the network as
> a service or volume as a service projects. Can someone point us to
> them?
>
> Thanks!
> jay

Whew, Jay I thought you were advocating major changes in Cactus.  That would completely mess up my view of the world :)

https://blueprints.launchpad.net/nova/+spec/bexar-network-service
https://blueprints.launchpad.net/nova/+spec/bexar-extend-network-model
https://blueprints.launchpad.net/nova/+spec/bexar-network-service


It was discussed at ODS, but I have not seen any code or momentum, to date.

I think it is worth while to have an open discussion about what if any of this can be safely done in Cactus.  I like you, Jay, feel a bit conservative.  I think we lost focus of the reason we chose time based releases. It is time to focus on nova being a solid trustworthy platform.  Features land when they are of sufficient quality, releases contain only the features that passed muster.

I will be sending an email about the focus and theme of Cactus in a little while.

Rick





_______________________________________________
Mailing list: https://launchpad.net/~openstack
Post to     : openstack@xxxxxxxxxxxxxxxxxxx
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp