openstack team mailing list archive

[Andy Smith <andyster@xxxxxxxxx>]

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 <openstack-bounces%2Bjohn>=openstack.org@
> lists.launchpad.net] 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
>