+1 On Jan 31, 2011, at 10:40 AM, John Purrier 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. > > 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:[email protected]] 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 > Post to : [email protected] > Unsubscribe : https://launchpad.net/~openstack > More help : https://help.launchpad.net/ListHelp > > > _______________________________________________ > Mailing list: https://launchpad.net/~openstack > Post to : [email protected] > Unsubscribe : https://launchpad.net/~openstack > More help : https://help.launchpad.net/ListHelp
_______________________________________________ Mailing list: https://launchpad.net/~openstack Post to : [email protected] Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
