Open Stack

More inline. I trimmed your agrees.

On 2/18/11 10:27 AM, "Jay Pipes" <jaypipes at gmail.com> 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
queue message. 


>
>> 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
>standardization process.

Wouldn't you be designing the same thing over 2 interfaces then? You'd
have to standardize on amqp and http?

>
>Just some thoughts,
>jay