[openstack-dev] [Marconi] Why is marconi a queue implementation vs a provisioning API?

Thierry Carrez thierry at openstack.org
Wed Mar 19 11:49:37 UTC 2014


Flavio Percoco wrote:
> On 19/03/14 10:17 +1300, Robert Collins wrote:
>> My desires around Marconi are:
>> - to make sure the queue we have is suitable for use by OpenStack
>> itself: we have a very strong culture around consolidating technology
>> choices, and it would be extremely odd to have Marconi be something
>> that isn't suitable to replace rabbitmq etc as the queue abstraction
>> in the fullness of time.
> 
> Although this could be done in the future, I've heard from many folks
> in the community that replacing OpenStack's rabbitmq / qpid / etc layer
> with Marconi is a no-go. I don't recall the exact reasons now but I
> think I can grab them from logs or something (Unless those folks are
> reading this email and want to chime in). FWIW, I'd be more than happy
> to *experiment* with this in the future. Marconi is definitely not ready
> as-is.

That's the root of this thread. Marconi is not really designed to cover
Robert's use case, which would be to be consumed internally by OpenStack
as a message queue.

I classify Marconi as an "application building block" (IaaS+), a
convenient, SQS-like way for cloud application builders to pass data
around without having to spin up their own message queue in a VM. I
think that's a relevant use case, as long as performance is not an order
of magnitude worse than the "spin up your own in a VM" alternative.
Personally I don't consider "serving the internal needs of OpenStack" as
a feature blocker. It would be nice if it could, but the IaaS+ use case
is IMHO compelling enough.

-- 
Thierry Carrez (ttx)

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 901 bytes
Desc: OpenPGP digital signature
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140319/81bf39c3/attachment.pgp>


More information about the OpenStack-dev mailing list