On Mon, Jan 31, 2011 at 10:40 AM, John Purrier <[email protected]> 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:[email protected]] > *Sent:* Friday, January 28, 2011 4:06 PM > > *To:* John Purrier > *Cc:* Rick Clark; Jay Pipes; Ewan Mellor; Søren Hansen; > [email protected] > *Subject:* Re: [Openstack] Network Service for L2/L3 Network > Infrastructure blueprint > > > > > > On Fri, Jan 28, 2011 at 1:19 PM, John Purrier <[email protected]> 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:[email protected]] > *Sent:* Friday, January 28, 2011 12:45 PM > *To:* John Purrier > *Cc:* Rick Clark; Jay Pipes; Ewan Mellor; Søren Hansen; > [email protected] > > > *Subject:* Re: [Openstack] Network Service for L2/L3 Network > Infrastructure blueprint > > > > > > On Fri, Jan 28, 2011 at 10:18 AM, John Purrier <[email protected]> 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: [email protected] [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; [email protected] > 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 <[email protected]> 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 : [email protected] > 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 : [email protected] > 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 ~~~~~~~~~~~~~~~~~~~~~~~~~~~
_______________________________________________ Mailing list: https://launchpad.net/~openstack Post to : [email protected] Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
