openstack team mailing list archive

[Justin Santa Barbara <justin@xxxxxxxxxxxx>]

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.voccio@xxxxxxxxxxxxx>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" <jaypipes@xxxxxxxxx> 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
> ><justin@xxxxxxxxxxxx> 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 <jaypipes@xxxxxxxxx> wrote:
> >>>
> >>> On Thu, Feb 17, 2011 at 6:57 PM, Justin Santa Barbara
> >>> <justin@xxxxxxxxxxxx> 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 abuse@xxxxxxxxxxxxx, and delete the original message.
> Your cooperation is appreciated.
>
>