John, I would agree with putting deployability at the top of the list. Right now, it is operational from a developers point of view. I think a true operations team would struggle supporting it at scale.
A change I might suggest in priority is moving the API up in the list. While the OS API is usable from a developers perspective, it isn't yet in a place where it can drive real value to the community. If we miss the Cactus release without having a complete API I think we run a risk of it not being relevant in the long term. Paul From: John Purrier <j...@openstack.org<mailto:j...@openstack.org>> Date: Mon, 31 Jan 2011 13:05:34 -0600 To: 'Thierry Carrez' <thie...@openstack.org<mailto:thie...@openstack.org>>, <openstack@lists.launchpad.net<mailto:openstack@lists.launchpad.net>> Subject: Re: [Openstack] Cactus Release Preparation I would suggest that the theme(s) for the Cactus release be: a. Deployability. This includes consistent packaging and deployment tools support; but also includes good consistent documentation, approachability to the project (how quickly can a novice get a running system going for proof of concept), and deployability at larger scale (includes reference materials around hardware and networking choices, operational concerns, and multi-machine deployment orchestration). b. Stability. Agree with both Rick and Thierry, we need to get the existing features stable and available for additional and larger scale testing environments. We will be focusing on providing additional test automation, beyond testing into automated functional testing. Contributors such as Rackspace will be setting up larger testing environments (on the order of hundreds of machines) to ensure that we are stable at scale, as well. c. Reliability. Once a configuration is stood up and operational, it needs to run with only normal operational attention. This will mean additional attention to operational concerns such as longer term test runs, memory leak detection, working set evaluation, etc. d. Consistency. Thierry is right on, we need to have OpenStack be consistent intra-project and across projects. This will include looking at scenarios that "break" our goals of being hypervisor agnostic, API definitions and approach, developer documentation, and other areas that teams might be optimizing locally but create a "not finished" view of the project. e. OpenStack API completed. We need to complete a working set of API's that are consistent and inclusive of all the exposed functionality. The OpenStack API will be an amalgam of the underlying services, we need to ensure that the application developer experience is smooth and logical. The DirectAPI calls will be exposed to project developers and committers, but the public OpenStack API for application developers will need to be stable, repeatable, versioned, and extensible. Developer documentation will need to address the fact that the OpenStack API will consist of fixed and well known core calls, plus additional calls that will be introduced by services via the extension mechanisms. Thoughts? John -----Original Message----- From: openstack-bounces+john=openstack....@lists.launchpad.net<mailto:openstack-bounces+john=openstack....@lists.launchpad.net> [mailto:openstack-bounces+john=openstack....@lists.launchpad.net] On Behalf Of Thierry Carrez Sent: Monday, January 31, 2011 2:59 AM To: openstack@lists.launchpad.net<mailto:openstack@lists.launchpad.net> Subject: Re: [Openstack] Cactus Release Preparation Rick Clark wrote: > In Bexar was a feature release. We pushed lots of new features. The > focus of Nova development in Cactus is going to be testing and > stabilization. I wonder if we shouldn't say "consistency, testing and stabilization". Feature work should be concentrated in areas where the resulting software is not consistent, in covering the gaps left after a featureful release. The different groups have been pursuing specific scenarios, but as a project we want to make sure that the other combinations also work. Support IPv6 on FlatManager, for example, is clearly part of that. A complete toolset around the Openstack API, maybe have a plan to deprecate the objectstore... -- Thierry Carrez (ttx) Release Manager, OpenStack _______________________________________________ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net<mailto:openstack@lists.launchpad.net> Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp _______________________________________________ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net<mailto:openstack@lists.launchpad.net> Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp Confidentiality Notice: This e-mail message (including any attached or embedded documents) is intended for the exclusive and confidential use of the individual or entity to which this message is addressed, and unless otherwise expressly indicated, is confidential and privileged information of Rackspace. Any dissemination, distribution or copying of the enclosed material is prohibited. If you receive this transmission in error, please notify us immediately by e-mail at ab...@rackspace.com, and delete the original message. Your cooperation is appreciated.
_______________________________________________ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
