openstack team mailing list archive

[Dan Wendlandt <dan@xxxxxxxxxx>]

On Mon, Jan 31, 2011 at 10:40 AM, John Purrier <john@xxxxxxxxxxxxx> wrote:

> In order to bring this discussion to a close and get everyone on the same
> page for Cactus development, here is where we have landed:
>
>
>
> 1.       We will **not** be separating the network and volume controllers
> and API servers from the Nova project.
>

I think this is definitely the right move.


>
>
> 2.       On-going work to extend the Nova capabilities in these areas will
> be done within the existing project and be based on extending the existing
> implementation. The folks working on these projects will determine the best
> approach for code re-use, extending functionality, and potential integration
> of additional community contributions in each area.
>
>
>
> 3.       Like all efforts for Cactus, correct trade-offs must be made to
> maintain deployability, stability, and reliability (key themes of the
> release).
>
>
>
> 4.       Core design concepts allowing each service to horizontally scale
> independently, present public/management/event interfaces through a
> documented OpenStack API, and allow services to be deployed independently of
> each other must be maintained. If issues arise that do not allow the current
> code structure to support these concepts the teams should raise the issues
> and open discussions on how to best address.
>
>
>
> We will target the Diablo design summit to discuss and review the progress
> made on these services and determine if the best approach to the project has
> been made.
>
>
>
> Thoughts?
>
>
>
> John
>
>
>
> *From:* Andy Smith [mailto:andyster@xxxxxxxxx]
> *Sent:* Friday, January 28, 2011 4:06 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 1:19 PM, John Purrier <john@xxxxxxxxxxxxx> wrote:
>
> 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.
>
>
>
> So far that is all possible under the existing auspices of Nova. DirectAPI
> will happily sit in front of any of the services independently, any of the
> services when run can be configured with different instances of RabbitMQ to
> point at, DirectAPI supports a large amount of extensibility and pluggable
> managers/drivers support a bunch more.
>
>
>
> Decoupling of the code has always been a goal, as have been providing
> public, management, and extension APIs and we aren't doing so bad.
>
>
>
> I don't think we disagree about wanting to run things independently, but
> for the moment I have seen no convincing arguments for separating the
> codebase.
>
>
>
>
>
>
>
> 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.
>
>
>
> Where is this parallel work being done if not in a separate project?
>
>
>
> --andy
>
>
>
>
>
>
>
> 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 <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<https://launchpad.net/%7Eopenstack>
> Post to     : openstack@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~openstack<https://launchpad.net/%7Eopenstack>
> More help   : https://help.launchpad.net/ListHelp
>
>
>
>
>
> _______________________________________________
> Mailing list: https://launchpad.net/~openstack<https://launchpad.net/%7Eopenstack>
> Post to     : openstack@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~openstack<https://launchpad.net/%7Eopenstack>
> More help   : https://help.launchpad.net/ListHelp
>
>


-- 
~~~~~~~~~~~~~~~~~~~~~~~~~~~
Dan Wendlandt
Nicira Networks, Inc.
www.nicira.com | www.openvswitch.org
Sr. Product Manager
cell: 650-906-2650
~~~~~~~~~~~~~~~~~~~~~~~~~~~