[Openstack] Proposal to defer existing OS API v1.1 to Diablo, for greater stability in Cactus

Rick Clark rick at openstack.org
Wed Mar 30 22:16:42 UTC 2011


On 03/30/2011 04:54 PM, Justin Santa Barbara wrote:

> 
> I would like to propose a fallback scenario for Cactus release management
> purposes, which would free up Titan resources and get us a better, more
> stable API with greater client support:
> 
>    - We defer any non-essential changes in the V1.1 API to post-Cactus.
>    - We can then discuss these thoroughly at the design summit (I do not
>    believe we had a design summit discussion on these API changes, for timing
>    reasons)
>    - We make the V1.1 API a minimal extension to V1.0, to support the Cactus
>    features we're going to ship.  For example, Brian Waldon pointed out that we
>    would need a new element for the changePassword action, and for extensions
>    also.
>    - These minimal differences would be driven by the people that need them
>    (primarily the Titan team)  I am confident they're not going to be
>    introducing things that are not strictly necessary at this stage of the game
>    :-)
>    - We may have to postpone extensions that inject additional content into
>    existing elements, and stick to extensions that extend the URI space, so
>    that the XML schema for V1.1 is minimal.  Extension of existing elements
>    probably warrants a Design Summit discussion anyway.  We do not yet have any
>    (non-test) extensions that inject content.
>    - We would rename the current V1.1 API to V1.2 or V2.0 - we are just
>    deferring it to Diablo, not abandoning it.
>    - We could still ship the renamed API as "experimental", even in Cactus
>    - The goal is to focus resources on one API that will then work 100%.
>    - Yes, it's still sort of going to be two APIs, but if we're really lucky
>    we might get away with almost no 'switching' code.  For example, if we _add_
>    a URI or an action, a V1.0 client will never discover it.
>    - In particular, we want to avoid the output format changing between
>    versions wherever we can.
>    - I hope by virtue of this approach that Cactus will be 100% compatible
>    with existing v1.0 (CloudServers) clients
>    - I hope also that V1.0 clients can just switch to use the V1.1 endpoint
>    when they're ready, and need make code changes only for things which have
>    actually changed.
> 
> 
> I believe this is entirely in line with our goals for Cactus.  I am less
> confident that the current V1.1 API is in line with our Cactus goals.
> 
> Thoughts?  Anyone from the Titan team want to comment on how they feel about
> the timetable for delivering the APIs in Cactus?  ttx?
> 

I 100% agree.

The 1.1 specs were handed over far too late for it to be reasonable to
get the work done in Cactus.  I am amazed at what the titan team has
accomplished.

I think that rackspace feels *very* strongly about getting the 1.1 done,
though.  John Purrier can answer that.

> 
> Justin
> 
> 
> 
> 
> _______________________________________________
> Mailing list: https://launchpad.net/~openstack
> Post to     : openstack at lists.launchpad.net
> Unsubscribe : https://launchpad.net/~openstack
> More help   : https://help.launchpad.net/ListHelp


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 262 bytes
Desc: OpenPGP digital signature
URL: <http://lists.openstack.org/pipermail/openstack/attachments/20110330/5a10fa71/attachment.sig>


More information about the Openstack mailing list