On Mon, Dec 2, 2013 at 10:12 PM, Jarret Raim <jarret.r...@rackspace.com>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. > The API and developer documentation is at http://docs.openstack.org/developer/oslo.messaging/ Doug > 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 > > > _______________________________________________ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > >
_______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
