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)
signature.asc
Description: OpenPGP digital signature
_______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
