[openstack-dev] [marconi] Reconsidering the unified API model

Gordon Sim gsim at redhat.com
Wed Jun 11 09:19:30 UTC 2014


On 06/10/2014 09:59 PM, Mark McLoughlin wrote:
> Now why is there a desire to implement these requirements using
> traditional message brokers?

I would speculate that any desire to utilise a message broker as opposed 
to a database would be to achieve different performance characteristics 
for the service.

E.g. a message broker might be optimised for high throughput and low 
latency, a database for handling very large queues and random access to 
messages.

However if the interface through which the service is used requires 
random access to messages and polling then any perceived benefits of 
using a broker may not be realised anyway.

> And what Marconi API semantics are impossible to implement using
> traditional message brokers?
>
> Either those semantics are fundamental requirements for this API, or the
> requirement to have support for traditional message brokers is the
> fundamental requirement. We can't have it both ways.

I suspect is is a question of understanding the expected performance 
metrics, the impact on those that aspects of the API design may have, 
and whether those aspects are intrinsic to the semantic requirements.

Is there an explicit list of requirements for Marconi anywhere? I've 
seen the use cases, which are useful. What would be the expected message 
rates and latencies for these patterns?

--Gordon.




More information about the OpenStack-dev mailing list