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.<div>
<br></div><div>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.</div>
<div><br clear="all">Justin<br><br><br><br>
<br><br><div class="gmail_quote">On Fri, Feb 18, 2011 at 6:31 AM, Paul Voccio <span dir="ltr"><<a href="mailto:paul.voccio@rackspace.com">paul.voccio@rackspace.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
Jay,<br>
<br>
I understand Justin's concern if we move /network and /images and /volume<br>
to their own endpoints then it would be a change to the customer. I think<br>
this could be solved by putting a proxy in front of each endpoint and<br>
routing back to the appropriate service endpoint.<br>
<br>
I added another image on the wiki page to describe what I'm trying to say.<br>
<div class="im"><a href="http://wiki.openstack.org/api_transition" target="_blank">http://wiki.openstack.org/api_transition</a><br>
<br>
</div>I think might not be as bad of a transition since the compute worker would<br>
receive a request for a new compute node then it would proxy over to the<br>
admin or public api of the network or volume node to request information.<br>
It would work very similar to how the queues work now.<br>
<br>
pvo<br>
<div><div></div><div class="h5"><br>
On 2/17/11 8:33 PM, "Jay Pipes" <<a href="mailto:jaypipes@gmail.com">jaypipes@gmail.com</a>> wrote:<br>
<br>
>Sorry, I don't view the proposed changes from AMQP to REST as being<br>
>"customer facing API changes". Could you explain? These are internal<br>
>interfaces, no?<br>
><br>
>-jay<br>
><br>
>On Thu, Feb 17, 2011 at 8:13 PM, Justin Santa Barbara<br>
><<a href="mailto:justin@fathomdb.com">justin@fathomdb.com</a>> wrote:<br>
>> An API is for life, not just for Cactus.<br>
>> I agree that stability is important.  I don't see how we can claim to<br>
>> deliver 'stability' when the plan is then immediately to destablize<br>
>> everything with a very disruptive change soon after, including customer<br>
>> facing API changes and massive internal re-architecting.<br>
>><br>
>><br>
>> On Thu, Feb 17, 2011 at 4:18 PM, Jay Pipes <<a href="mailto:jaypipes@gmail.com">jaypipes@gmail.com</a>> wrote:<br>
>>><br>
>>> On Thu, Feb 17, 2011 at 6:57 PM, Justin Santa Barbara<br>
>>> <<a href="mailto:justin@fathomdb.com">justin@fathomdb.com</a>> wrote:<br>
>>> > Pulling volumes & images out into separate services (and moving from<br>
>>> > AMQP to<br>
>>> > REST) sounds like a huge breaking change, so if that is indeed the<br>
>>>plan,<br>
>>> > let's do that asap (i.e. Cactus).<br>
>>><br>
>>> Sorry, I have to disagree with you here, Justin :)  The Cactus release<br>
>>> is supposed to be about stability and the only features going into<br>
>>> Cactus should be to achieve API parity of the OpenStack Compute API<br>
>>> with the Rackspace Cloud Servers API. Doing such a huge change like<br>
>>> moving communication from AMQP to HTTP for volume and network would be<br>
>>> a change that would likely undermine the stability of the Cactus<br>
>>> release severely.<br>
>>><br>
>>> -jay<br>
>><br>
>><br>
<br>
<br>
<br>
</div></div><div><div></div><div class="h5">Confidentiality Notice: This e-mail message (including any attached or<br>
embedded documents) is intended for the exclusive and confidential use of the<br>
individual or entity to which this message is addressed, and unless otherwise<br>
expressly indicated, is confidential and privileged information of Rackspace.<br>
Any dissemination, distribution or copying of the enclosed material is prohibited.<br>
If you receive this transmission in error, please notify us immediately by e-mail<br>
at <a href="mailto:abuse@rackspace.com">abuse@rackspace.com</a>, and delete the original message.<br>
Your cooperation is appreciated.<br>
<br>
</div></div></blockquote></div><br></div>