Open Stack

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 <john at openstack.org<mailto:john at openstack.org>>
Date: Mon, 31 Jan 2011 13:05:34 -0600
To: 'Thierry Carrez' <thierry at openstack.org<mailto:thierry at openstack.org>>, <openstack at lists.launchpad.net<mailto:openstack at 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.org at lists.launchpad.net<mailto:openstack-bounces+john=openstack.org at lists.launchpad.net> [mailto:openstack-bounces+john=openstack.org at lists.launchpad.net] On Behalf Of Thierry Carrez
Sent: Monday, January 31, 2011 2:59 AM
To: openstack at lists.launchpad.net<mailto:openstack at 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 at lists.launchpad.net<mailto:openstack at lists.launchpad.net>

Unsubscribe : https://launchpad.net/~openstack

More help   : https://help.launchpad.net/ListHelp

_______________________________________________ Mailing list: https://launchpad.net/~openstack Post to : openstack at lists.launchpad.net<mailto:openstack at 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 abuse at rackspace.com, and delete the original message.
Your cooperation is appreciated.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack/attachments/20110131/8d5cd8c1/attachment.html>