> 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. 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. 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 again for all the eyeballs our on application. Jarret
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev