Open Stack

Excerpts from Nikolay Makhotkin's message of 2015-08-19 17:16:14 +0300:
> Hi, Davanum!
> 
> Have you already read the thread [1]? It is about acknowledge feature in
> oslo.messaging. Particularly, about the absent of this feature in
> oslo.messaging.
> 
> The guys from messaging said that it is very problematically to add that
> kind of feature to oslo.messaging because it does not fit to
> oslo.messaging's approach.

The Oslo libraries are meant to evolve as the needs to the applications
evolve. That process works best when it comes about through
collaboration between all of us, and the Oslo team has taken on the
mission of enabling that collaboration. What I'm hearing in this
request is "the library our community has written doesn't do something
we want, so rather than work on it with other members of our community
we want to adopt a different library that is missing different
features" [2].

As far as I can tell from reading the thread you linked to, you
weren't told "no" just that it might be harder than just moving the
place we send acknowledgments inside the current driver, and we're
likely to need your help with the implementation.  The thread sort
of died off, so perhaps that wasn't clear.

You have what seems to be a new case -- perhaps its an old case
that was never being handled properly and everyone actually always
wanted this, I don't know. Either way, handling that case will
require a change to the semantics of the library, which means we
need to be careful about how we do it, but it's not impossible or
unwanted.

However we implement it, we need to ensure backwards compatibility
for applications relying on the current behavior. For example,
perhaps the application would pass a flag to the messaging library
to control whether ACKs are sent before or after processing (we
don't want that as a configuration option, because it's the application
developer who needs to handle any differences in behavior, rather
than the deployer). We should start out with the default behavior
set to what we have now, and then we can experiment with changing
it in each application before changing the default in the library.

So, if you're interested in working with us on that, let us know.

Doug

[2] pika does not yet support Python 3, and would require work within
the application to set up configuration options that would then be
different from the options used in other OpenStack applications.

> 
> [1] http://lists.openstack.org/pipermail/openstack-dev/2015-July/068806.html
> 
> On Wed, Aug 19, 2015 at 2:35 PM, Davanum Srinivas <davanum at gmail.com> wrote:
> 
> > Nikolay,
> >
> > Do you mean that you will *NOT* use oslo.messaging and use pika directly.
> > I'd strongly discourage that possibility.
> >
> > Few members on the oslo.messaging team are looking at pika library already
> > and are doing a prototype:
> >
> > https://github.com/dukhlov/oslo.messaging/blob/master/oslo_messaging/_drivers/impl_pika.py
> >
> > If you are interested in that effort, please let us know.
> >
> > Thanks,
> > Dims
> >
> >
> > On Wed, Aug 19, 2015 at 7:21 AM, Nikolay Makhotkin <
> > nmakhotkin at mirantis.com> wrote:
> >
> >> Hi, folks!
> >>
> >> Recently we've had the discussion with oslo.messaging team about
> >> acknowledge feature in RabbitMQ:
> >> http://lists.openstack.org/pipermail/openstack-dev/2015-July/068806.html
> >>
> >> After that Mistral team did the research about using *kombu *or *pika*
> >> library for implementation of remote procedure call server. Both kombu and
> >> pika was met our requirements. But we would prefer to use *pika* by next
> >> reasons:
> >>
> >>  1. It is less complex than *kombu*;
> >>  2. *kombu* itself is abstraction of messaging (but we don't need that);
> >>  3. We had the discussion with one of RabbitMQ developer which advised us
> >> to use *pika* (comparing to *kombu*)
> >>
> >>
> >> Is it possible to add *pika *to the global-requirements for our needs?
> >>
> >> Thanks.
> >> --
> >> Best Regards,
> >> Nikolay
> >> @ Mirantis Inc.
> >>
> >> __________________________________________________________________________
> >> 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
> >
> > __________________________________________________________________________
> > 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
> >
> >
>