On 03/12/13 03:12 +0000, Jarret Raim wrote:
There are two big parts to this, I think. One is techincal - a significant portion of OpenStack deployments will not work with this because Celery does not work with their deployed messaging architecture. See another reply in this thread for an example of someone that sees the inability to use Qpid as a roadblock for an example. This is solvable, but not quickly.The other is somewhat technical, but also a community issue. Monty articulated this well in another reply. Barbican has made a conflicting library choice with what every other project using messaging is using. With the number of projects we have, it is in our best interest to strive for consistency where we can. Differences should not be arbitrary. The differences should only be where an exception is well justified. I don't see that as being the case here. Should everyone using oslo.messaging (or its predecessor rpc in oslo-incubator) be using Celery? Maybe. I don't know, but that's the question at hand. Ideally this would have come up with a more broad audience sooner. If it did, I'm sorry I missed it.I understand the concern here and I'm happy to have Barbican look at using oslo.messaging during the Icehouse cycle. I am a bit surprised at the somewhat strong reactions to our choice. When we created Barbican, we looked at the messaging frameworks out there for use. At the time, oslo.messaging was not packaged, not documented, not tested, had no track record and an unknown level of community support.
But there was oslo-incubator/rpc which all projects where already using.
Celery is a battle-tested library that is widely deployed with a good track record, strong community and decent documentation. We made our choice based on those factors, just as the same as we would for any library inclusion. As celery has met our needs up to this point, we saw no reason to revisit the decision until now. In that time oslo.messaging has moved to a separate repo. It still has little to no documentation, but the packaging and maintenance issues seem to be on the way to being sorted. So in short, in celery we get a reliable library with good docs that is battle tested, but is limited to the transports supported by Kombu. Both celery and Kombu are extendable and have many backends including AMQP, Redis, Beanstalk, Amazon SQS, CouchDB, MongoDB, ZeroMQ, ZooKeeper, SoftLayer MQ and Pyro. Oslo.messaging seems to have good support in OpenStack, but still lacks documentation and packaging (though some of that is being sorted out now). It offers support for qpid which celery seems to lack. It also offers a common place for message signing and some other nice to have features for OpenStack.
I think there's something else you should take under consideration. Oslo messaging is not just an OpenStack library. It's the RPC library that all projects are relying on and one of the strong goals we have in OpenStack is to reduce code and efforts duplications. We'd love to have more people testing and contributing to oslo.messaging in order to make it as battle tested as celery is. Please, don't get me wrong. I don't mean to say you didn't considered it, I just want to add another reason why we should always try to re-use the libraries that other projects are using - unless there's a strong technical reason ;).
Based on the commonality in OpenStack (and the lack of anyone else using Celery), I think looking to move to oslo.messaging is a good goal. This will take some time, but I think doing it by Icehouse seems reasonable. I think that is what you and Monty are asking for?
I have added the task to our list on https://wiki.openstack.org/wiki/Barbican/Incubation.
Thanks a lot for this, really! Cheers, FF -- @flaper87 Flavio Percoco
pgpznZ7d3tIAe.pgp
Description: PGP signature
_______________________________________________ OpenStack-dev mailing list [email protected] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
