openstack team mailing list archive
Mailing list archive
Re: Network Service for L2/L3 Network Infrastructure blueprint
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.
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.
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.
From: openstack-bounces+john=openstack.org@xxxxxxxxxxxxxxxxxxx [mailto:openstack-bounces+john=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
Whew, Jay I thought you were advocating major changes in Cactus. That would completely mess up my view of the world :)
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.