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 : [email protected] > Unsubscribe : https://launchpad.net/~openstack > More help : https://help.launchpad.net/ListHelp
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Mailing list: https://launchpad.net/~openstack Post to : [email protected] Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp

