Open Stack

Hey,

Does the PPB vote last night mean that the all-mighty PPB, in its
infinite wisdom, has decreed that nothing useful can come from further
discussion? :-)

I certainly hope not ...

On Tue, 2012-06-19 at 11:07 -0700, Monty Taylor wrote:
> It is terrible for the public cloud implementations who are doing
> rolling releases - [..] - it is a terrible experience for the
> end-users of OpenStack public clouds.
> 
> I'm going to use myself as an example, because it's specific.
> 
> A few months ago, HP Cloud added keystone-based auth to their
> diablo-based public cloud. This was before essex released. This meant
> that to use HP Cloud's public service, there were two choices:
> 
> - trunk python-novaclient
> - crazy library released directly from HP

[..]

Snipping heavily, but your point is well taken.

Basically, that even before OpenStack does an official release of a
server implementing a given API, there will exist public clouds which
expose that API.

The OpenStack project should support public cloud users by making
available officially supported clients of such APIs as soon as they are
available in such public clouds.

Got it.


That actually goes to something I'm not aware of us - the project -
having spent much time discussing. We do twice yearly releases of our
collection of software, but there are public cloud providers which want
to essentially do continuous deployment from our development branch.

To what extent is that a reasonable thing for the project to support? If
we had a shorter release cycle, would the cloud providers switch their
deployments from continuous to the releases? If not, can the project and
cloud providers better co-ordinate somehow?

(We should avoid rat-holing on the broader questions, but I just wanted
to echo your "usage patterns we're trying to find the right compromise
for" thing)


I think the specific question to consider here is:

  At what point is a new REST API in our development branch officially 
  blessed by the project? When do we say "that's done, we won't make 
  any future incompatible changes"?

I don't think OpenStack should encourage cloud providers to make such
new APIs publicly available until that time. Nor should we do official
releases of client libraries supporting those new APIs until that time.


For argument sake, and given a 6 month cycle, say that's 2 months before
the release date. For Folsom, that's the folsom-3 milestone.

Before that date, the project recommends that public cloud providers
deploying Folsom from our development branch does not expose any of the
new REST APIs which were added in Folsom. Assume we have provided a
mechanism (e.g. a config option) to make that possible.

That means that we don't need a release of client libs with support for
those APIs until folsom-3.


Now, back to the "streams" we talked about yesterday:

  1) bugfixes
  2) new client lib features built on top of existing REST API features 
  3) new client lib features built on top of new REST API features 

It seems to me that the "stream" the project releases to pypi should be
(1) and (2) continuously, but only after we hit e.g. folsom-3 should we
do a release of (3) to pypi.


e.g. I could see us doing this:

  - When we hit essex-3, we did the first release of the client libs 
    which supported new REST APIs added in Essex

  - We continue adding bugfixes and new client lib features based on the
    essex APIs to the master branch of the client project

  - At Essex release time, we do another release of the client libs ... 
    purely to co-ordinate with the project release

  - We continue doing releases as the need arises

  - At some point, new REST APIs are added in Folsom and we want the 
    client lib to support it. At that point, we branch off an 'essex' 
    branch of the lib. Support for those new REST APIs goes into 
    master, everything else goes into both.

  - We continue doing releases from the essex branch

  - When we hit folsom-3, the REST APIs freeze and we do our first
    release containing support for the new REST APIs added in Folsom

  - Perhaps the essex branch switches to bugfix mode since essex 
    distros won't switch to the folsom client libs


How does that sound?

Cheers,
Mark.