Re: [openstack-dev] [oslo][messaging] configurable ack-then-process (at least/most once) behavior

[Bogdan Dobrelya]

On 30.11.2015 14:28, Bogdan Dobrelya wrote:
> Hello.
> Please let's make this change [0] happen to the Oslo messaging.
> This is reasonable, straightforward and backwards compatible change. And
> it is required for OpenStack applications - see [1] - to implement a
> sane HA. The only thing left is to cover this change by unit tests.
> 
> [0] https://review.openstack.org/229186
> [1]
> http://lists.openstack.org/pipermail/openstack-dev/2015-October/076217.html
> 

Here is related bp [0]. I will submit the spec as well and put there all
of the concerns Mehdi Abaakouk provided in the aforementioned patch
review process. I believe the ack-then-process pattern *has* use cases,
that is why this topic will be raised again and again unless adressed.

[0]
https://blueprints.launchpad.net/oslo.messaging/+spec/at-least-once-guarantee


-- 
Best regards,
Bogdan Dobrelya,
Irc #bogdando

__
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

Re: [openstack-dev] [oslo][messaging] configurable ack-then-process (at least/most once) behavior

[Nikola Đipanov]

On 11/30/2015 01:28 PM, Bogdan Dobrelya wrote:
> Hello.
> Please let's make this change [0] happen to the Oslo messaging.
> This is reasonable, straightforward and backwards compatible change. And
> it is required for OpenStack applications - see [1] - to implement a
> sane HA. The only thing left is to cover this change by unit tests.
> 
> [0] https://review.openstack.org/229186
> [1]
> http://lists.openstack.org/pipermail/openstack-dev/2015-October/076217.html
> 

I've also looked into doing something like this for a use case very
similar to Mistral a few months back, and my investigation came to a
similar conclusion to what Medhi (sileht) commented on the above patch -
you can't do this because it changes the semantics of current cast and
call methods based on how the server is declared without the client
being aware - that's a bad way to design an API.

What I came up with as a possible design back then, in case you want to
use oslo.messaging to dispatch async tasks that should be done at least
once (for example to be safe against worker crashing), is add a new
method to the oslo.messaging client interface.

For example - we may want to call it something like ensure() or similar
so that it is clear what the semantics are, and we want to be careful to
not tie it's semantics to the AMQP model too much.

I haven't looked into how it can be implemented in depth, but it would
surely be more than your above patch, as you would need to evolve
several interfaces in oslo.messaging to make this happen.

I'm not an oslo.messaging maintainer, and am actually a total bystander
in this matter so feel free to disregard this as an irrelevant opinion,
however maybe Mehdi and some of the oslo.messaging folks will comment
further.

N.

__
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

Re: [openstack-dev] [oslo][messaging] configurable ack-then-process (at least/most once) behavior

[Davanum Srinivas]

Bogdan,

Which service would use this flag to start with? and how would the
code change to provide "app side is fully responsible for duplicates
handling"?

Thanks,
Dims

On Tue, Dec 1, 2015 at 4:27 AM, Bogdan Dobrelya  wrote:
> On 30.11.2015 14:28, Bogdan Dobrelya wrote:
>> Hello.
>> Please let's make this change [0] happen to the Oslo messaging.
>> This is reasonable, straightforward and backwards compatible change. And
>> it is required for OpenStack applications - see [1] - to implement a
>> sane HA. The only thing left is to cover this change by unit tests.
>>
>> [0] https://review.openstack.org/229186
>> [1]
>> http://lists.openstack.org/pipermail/openstack-dev/2015-October/076217.html
>>
>
> Here is related bp [0]. I will submit the spec as well and put there all
> of the concerns Mehdi Abaakouk provided in the aforementioned patch
> review process. I believe the ack-then-process pattern *has* use cases,
> that is why this topic will be raised again and again unless adressed.
>
> [0]
> https://blueprints.launchpad.net/oslo.messaging/+spec/at-least-once-guarantee
>
>
> --
> Best regards,
> Bogdan Dobrelya,
> Irc #bogdando
>
> __
> 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

__
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

[openstack-dev] [oslo][messaging] configurable ack-then-process (at least/most once) behavior

[Bogdan Dobrelya]

Hello.
Please let's make this change [0] happen to the Oslo messaging.
This is reasonable, straightforward and backwards compatible change. And
it is required for OpenStack applications - see [1] - to implement a
sane HA. The only thing left is to cover this change by unit tests.

[0] https://review.openstack.org/229186
[1]
http://lists.openstack.org/pipermail/openstack-dev/2015-October/076217.html

-- 
Best regards,
Bogdan Dobrelya,
Irc #bogdando

__
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