openstack team mailing list archive
Mailing list archive
Re: OpenStack Compute API 1.1
More inline. I trimmed your agrees.
On 2/18/11 10:27 AM, "Jay Pipes" <jaypipes@xxxxxxxxx> wrote:
>> 5) Interested developers can get involved in only the services that
>>they care about without worrying about other services.
>Not quite sure how this has to do with REST vs. AMQP... AMQP is simply
>the communication protocol between internal Nova services (network,
>compute, and volume) right now. Developers can currently get involved
>in the services they want to without messing with the other services.
I think means other services will have apis that sit on a different
endpoint than compute. To talk to it, use the http interface instead of a
>> 6) We already have 3 APIs (nova, swift, glance), we need to do this
>>kind of integration as it is, it makes sense for us to standardize on it.
>Unless I'm mistaken, we're not talking about APIs. We're talking about
>protocols. AMQP vs. HTTP.
Its a bit of both. To break out into separate apis we wouldn't use amqp to
communicate between services.
>> We are certainly changing the way we are doing things, but I don't
>>really think we are throwing away a lot of functionality. As PVO
>>mentioned, things should work very similar to the way they are working
>>now. You still have compute workers, you may still have an internal
>>queue, the only difference is that cross-service communication is now
>>happening by issuing REST calls.
>I guess I'm on the fence with this one. I agree that:
>* Having clear boundaries between services is A Good Thing
>* Having versioning in the interfaces between services is A Good Thing
>I'm just not convinced that services shouldn't be able to communicate
>on different protocols. REST over HTTP is a fine interface. Serialized
>messages over AMQP is similarly a fine interface. The standardization
>should occur at the *message* level, not the *protocol* level. REST
>over HTTP, combined with the Atom Publishing Protocol, has those
>messages already defined. Having standard message definitions that are
>sent via AMQP seems to me to be the "missing link" in the
Wouldn't you be designing the same thing over 2 interfaces then? You'd
have to standardize on amqp and http?
>Just some thoughts,