On 28/05/15 07:34 -0400, Davanum Srinivas wrote:
Flavio,PIka is an unknown quantity at the moment as none of us have touched it. It was brought up by rabbitmq folks. So someone should look at it. We don't have have enough info either to say we should use Pika by itself or as a kombu driver. We may have to make that determination at some point in the future if indeed pika is so much better. We don't have anyone in the Kombu community either...and Pika will need to pass the python34, licensing etc as well to be considered in addition to the performance.
I'm here from the Kombu community[0] (although I haven't done much lately). I think we should consider contributing back before dropping kombu if we ever get to the point where we think pika is better than whatever kombu is using. Flavio [0] https://github.com/orgs/celery/people
thanks, dims On Thu, May 28, 2015 at 7:08 AM, Flavio Percoco <fla...@redhat.com> wrote:On 27/05/15 10:24 -0700, Joshua Harlow wrote:Thanks dims!indeed, thanks. [snip]Also for the pika one, I'd really like to understand why not kombu. I don't know enough of the background, but from that session it looks like we need to do some comparative analysis (and imho get feedback from asksol[1] and others) before we go to deep down that rabbit hole (no jump to another 'greener pasture' imho should be done without all of this, to avoid pissing off the two [kombu, pika] communities).I couldn't attend this session but I'd also like to understand what's the idea behind using pika instead of kombu. FWIW, older versions of kombu used pika and it was moved away from it. One of the reasons was that pika was not stable enough at that time. This could've changed. If pika is just better than the amqp lib used by Kombu, wouldn't it be better to just contribute back to kombu? Cheers, FlavioMy 2 cents :-P [1] https://github.com/ask -Josh Davanum Srinivas wrote:Hi Team, Here are the etherpads from the summit[1]. Some highlights are as follows: Oslo.messaging : Took status of the existing zmq driver, proposed a new driver in parallel to the existing zmq driver. Also looked at possibility of using Pika with RabbitMQ. Folks from pivotal promised to help with our scenarios as well. Oslo.rootwrap : Debated daemon vs a new privileged service. The Nova change to add rootwrap as daemon is on hold pending progress on the privsep proposal/activity. Oslo.versionedobjects : We had a nice presentation from Dan about what o.vo can do and a deepdive into what we could do in next release. Taskflow : Josh and team came up with several new features and how to improve usability We will also have several new libraries in Liberty (oslo.cache, oslo.service, oslo.reports, futurist, automaton etc). We talked about our release processes, functional testing, deprecation strategies and debated a but about how best to move to async models as well. Please see etherpads for detailed information. thanks, dims [1] https://wiki.openstack.org/wiki/Design_Summit/Liberty/Etherpads#Oslo__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev-- @flaper87 Flavio Percoco __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev-- Davanum Srinivas :: https://twitter.com/dims
-- @flaper87 Flavio Percoco
pgpkFZlf38ZFx.pgp
Description: PGP signature
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
