Open Stack

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.

thanks,
dims

On Thu, May 28, 2015 at 7:08 AM, Flavio Percoco <flavio at 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,
> Flavio
>
>>
>> My 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-request at 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-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



-- 
Davanum Srinivas :: https://twitter.com/dims