On Wednesday, March 30, 2011 6:16pm, "Rick Clark" <[email protected]> said:
> _______________________________________________ > Mailing list: https://launchpad.net/~openstack > Post to : [email protected] > Unsubscribe : https://launchpad.net/~openstack > More help : https://help.launchpad.net/ListHelp > 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 > > > So first, I apologize that it hasn't been easy to see the exact state of the 1.0 and 1.1 APIs in an easy way. I'd start by giving an update on where those two versions of the APIs stand. API v1.0: The guys on titan and ozone did a lot of work to bring this very close to spec this release, and it is much more usable than it was prior to cactus. There are already some bugs filed on this (the largest one I know of off the top of my head is that rebuild is not supported - Brians Lamar and Waldon are close to completing this). Missing Features: - Shared IP Groups - Scheduled Backups I think these are relatively minor in the scheme of things, but I leave that to you to decide. The biggest gap in my mind is the difference between the spec and implementation in terms of the XML format. We have discussed a few ways to deal with this in IRC and locally, but by and large I think this is something too big to make it into cactus, whichever route we take. The fix is in coming up with a sane serialization mechanism; someone on titan will file a blueprint about this very soon. API v1.1: Again, we got pretty close on this as well. Missing Features - Affinity ID - IPv6 Support at the OS API level Again, the format of data is the big gap. In this case, the json is closer to the 1.0 style rather than the 1.1 style. In addition, the XML data still suffers the same problems that 1.0 suffers from. Given this, what makes the most sense to me is to focus on stability for version 1.0 API excluding XML support. The bindings that are out there have strong support for the JSON data formats in v1.0. As suggested, I think we call the current mostly implemented 1.1 API experimental so as to give access to any features that we need that are only in 1.1. One point I would like to ask about is how important is XML to the 1.0 implementation? We can potentially come up with some short term fixes for the currently off-spec XML, but they aren't anything that I would be happy keeping long term. My preference is to not worry about it now and fix it with a well thought-out long term solution around serialization in Diablo, but wanted input on this. I'd like to go with a lazy consensus model on this, if there are no objections in the next 24 hours, we will assume we aren't focusing on XML for Cactus. Then, I think we should talk about the API at the design conference and then very quickly after that act on decisions we make at that conference. I'd also like to take a minute to say why Rackspace cares about the 1.1 spec being relatively close to where it is now, and why I think its good for the OpenStack community. Our goal, which I hope is in alignment with the community's goals, is for us to deploy OpenStack as soon as possible. In order to do that, an API that is not drastically different from the current spec will be extremely helpful as we will be porting that spec over to the current API deployed at Rackspace. This work has not yet started, but it would still be very helpful for it to be close to what we have so that we can put as many people on Nova instead of the old code base as possible. Once we have an API that we are confident we can move to quickly and that we can support for a while before deprecating it, the API can evolve much more quickly without affecting the rackspace deployment, and we would be able to expose those new features to our customers. Having said that, I definitely understand that Rackspace is not the only player here. If this is not the right approach, we should fix that sooner rather than later with the understanding that it will absolutely affect the rate at which we can deploy OpenStack here. Thoughts? Gabe _______________________________________________ Mailing list: https://launchpad.net/~openstack Post to : [email protected] Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
