Jay: The AMQP->REST was the re-architecting I was referring to, which would not be customer-facing (other than likely introducing new bugs.) Spinning off the services, if this is visible at the API level, is much more concerning to me.
So Paul, I think the proxy is good because it acknowledges the importance of keeping a consistent API. But - if our API isn't finalized - why push it out at all, particularly if we're then going to have the overhead of maintaining another translation layer? For Cactus, let's just support EC2 and/or CloudServers 1.0 API compatibility (again a translation layer, but one we probably have to support anyway.) Then we can design the right OpenStack API at our leisure and meet all of our goals: a stable Cactus and stable APIs. If anyone ends up coding to a Cactus OpenStack API, we shouldn't have them become second-class citizens 3 months later. Justin On Fri, Feb 18, 2011 at 6:31 AM, Paul Voccio <paul.voc...@rackspace.com>wrote: > Jay, > > I understand Justin's concern if we move /network and /images and /volume > to their own endpoints then it would be a change to the customer. I think > this could be solved by putting a proxy in front of each endpoint and > routing back to the appropriate service endpoint. > > I added another image on the wiki page to describe what I'm trying to say. > http://wiki.openstack.org/api_transition > > I think might not be as bad of a transition since the compute worker would > receive a request for a new compute node then it would proxy over to the > admin or public api of the network or volume node to request information. > It would work very similar to how the queues work now. > > pvo > > On 2/17/11 8:33 PM, "Jay Pipes" <jaypi...@gmail.com> wrote: > > >Sorry, I don't view the proposed changes from AMQP to REST as being > >"customer facing API changes". Could you explain? These are internal > >interfaces, no? > > > >-jay > > > >On Thu, Feb 17, 2011 at 8:13 PM, Justin Santa Barbara > ><jus...@fathomdb.com> wrote: > >> An API is for life, not just for Cactus. > >> I agree that stability is important. I don't see how we can claim to > >> deliver 'stability' when the plan is then immediately to destablize > >> everything with a very disruptive change soon after, including customer > >> facing API changes and massive internal re-architecting. > >> > >> > >> On Thu, Feb 17, 2011 at 4:18 PM, Jay Pipes <jaypi...@gmail.com> wrote: > >>> > >>> On Thu, Feb 17, 2011 at 6:57 PM, Justin Santa Barbara > >>> <jus...@fathomdb.com> wrote: > >>> > Pulling volumes & images out into separate services (and moving from > >>> > AMQP to > >>> > REST) sounds like a huge breaking change, so if that is indeed the > >>>plan, > >>> > let's do that asap (i.e. Cactus). > >>> > >>> Sorry, I have to disagree with you here, Justin :) The Cactus release > >>> is supposed to be about stability and the only features going into > >>> Cactus should be to achieve API parity of the OpenStack Compute API > >>> with the Rackspace Cloud Servers API. Doing such a huge change like > >>> moving communication from AMQP to HTTP for volume and network would be > >>> a change that would likely undermine the stability of the Cactus > >>> release severely. > >>> > >>> -jay > >> > >> > > > > Confidentiality Notice: This e-mail message (including any attached or > embedded documents) is intended for the exclusive and confidential use of > the > individual or entity to which this message is addressed, and unless > otherwise > expressly indicated, is confidential and privileged information of > Rackspace. > Any dissemination, distribution or copying of the enclosed material is > prohibited. > If you receive this transmission in error, please notify us immediately by > e-mail > at ab...@rackspace.com, and delete the original message. > Your cooperation is appreciated. > >
_______________________________________________ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
