On Feb 18, 2011, at 9:34 AM, Jay Pipes wrote: > OK, fair enough. > > Can I ask what the impetus for moving from AMQP to REST for all > internal APIs is? Seems to me we will be throwing away a lot of > functionality for the benefit of cross-WAN REST communication? > > -jay
Not to mention building a queueing service whilst moving from AMQP to REST. Shouldn't we eat our own dog food? Mmm...kibbles. > > On Fri, Feb 18, 2011 at 9: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 _______________________________________________ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp