openstack team mailing list archive

[Jay Pipes <jaypipes@xxxxxxxxx>]

Hi Jorge! Thanks for the detailed response. Comments inline. :)

On Fri, Feb 18, 2011 at 11:02 AM, Jorge Williams
<jorge.williams@xxxxxxxxxxxxx> wrote:
> There are lots of advantages:
>
> 1) It allows services to be more autonomous, and gives us clearly defined service boundaries. Each service can be treated as a black box.

Agreed.

> 2) All service communication becomes versioned, not just the public API but also the admin API.  This means looser coupling which can help us work in parallel.  So glance can be on 1.2 of their API, but another API that depends on it (say compute) can continue to consume 1.1 until they're ready to switch -- we don't have the bottlenecks of everyone having to update everything together.

Agreed.

> 3) Also because things are loosely coupled and there are clearly defined boundaries  it positions us to have many other services (LBaaS, FWaaS, DBaaS, DNSaaS, etc).

Agreed.

> 4) It also becomes easier to deploy a subset of functionality ( you want compute and image, but not block).

Agreed.

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

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

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

Just some thoughts,
jay