Open Stack

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20131203/1a1029fa/attachment.pgp>