openstack team mailing list archive
-
openstack team
-
Mailing list archive
-
Message #01618
Re: Proposal to defer existing OS API v1.1 to Diablo, for greater stability in Cactus
-
To:
Justin Santa Barbara <justin@xxxxxxxxxxxx>
-
From:
Rick Clark <rick@xxxxxxxxxxxxx>
-
Date:
Wed, 30 Mar 2011 17:16:42 -0500
-
Cc:
openstack@xxxxxxxxxxxxxxxxxxx
-
In-reply-to:
<AANLkTinrOs4-Qs0641tijnKm2tq0SOan1V+V1u8b3r=d@mail.gmail.com>
-
Openpgp:
id=DF41F834
-
User-agent:
Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.15) Gecko/20110307 Lightning/1.0b2 Thunderbird/3.1.9
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@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~openstack
> More help : https://help.launchpad.net/ListHelp
Attachment:
signature.asc
Description: OpenPGP digital signature
References