[openstack-dev] [Marconi] Why is marconi a queue implementation vs a provisioning API?
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
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...
Size: 901 bytes
Desc: OpenPGP digital signature
More information about the OpenStack-dev