openstack team mailing list archive

["John Purrier" <john@xxxxxxxxxxxxx>]

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@xxxxxxxxxxxxxxxxxxx
[mailto:openstack-bounces+john=openstack.org@xxxxxxxxxxxxxxxxxxx] On Behalf
Of Thierry Carrez
Sent: Monday, January 31, 2011 2:59 AM
To: openstack@xxxxxxxxxxxxxxxxxxx
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@xxxxxxxxxxxxxxxxxxx
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp