Doug Hellmann wrote:
Excerpts from Renat Akhmerov's message of 2016-05-17 19:10:55 +0700:
Team,
Our stable/mitaka branch is now broken by oslo.messaging 5.0.0. Global
requirements for stable/mitaka has oslo.messaging>=4.0.0 so it can fetch 5.0.0.
Just reminding that it breaks us because we intentionally modified
RPCDispatcher like in [1]. It was needed for “at-least-once” delivery. In
master we already agreed to remove that hack and work towards having a decent
solution (there are options). The patch is [2]. But we need to handle it in
mitaka somehow.
Options I see:
Constrain oslo.messaging in global-requirements.txt for stable/mitaka with
4.6.1. Hard to do since it requires wide cross-project coordination.
Remove that hack in stable/mitaka as we did with master. It may be bad because
this was wanted very much by some of the users
Not sure what else we can do.
You could set up your test jobs to use the upper-constraints.txt file in
the requirements repo.
What was the outcome of the discussion about adding the at-least-once
semantics to oslo.messaging?
So there are a few options I am seeing so far (there might be more that
I don't see also), others can hopefully correct me if they are wrong
(which they might be) ;)
Option #1
Oslo.messaging (and the dispatcher part that does this) stays as is,
doing at-most-once for RPC (notifications are in a different category
here so let's not discuss them) and doing at-most-once well and
battle-hardened (it's current goal) across the various backend drivers
it supports.
At that point at-least-once will have to done via some other library
where this kind of semantics can be placed, that might be tooz via
https://review.openstack.org/#/c/260246/ (which has similar semantics,
but is not based on a kind of RPC, instead it's more like a job-queue).
Option #2
Oslo.messaging (and the dispatcher part that does this) changes
(possibly allowing it to be replaced with a different type of
dispatcher, ie like in https://review.openstack.org/#/c/314732/); the
default class continues being great at for RPC (notifications are in a
different category here so let's not discuss them) and doing
at-most-once well and battle-hardened (it's current goal) across the
various backend drivers it supports. If people want to provide an
alternate class with different semantics they are somewhat on there own
(but at least they can do this).
Issues raised: this though may not be wanted, as some of the
oslo.messaging folks do not want the dispatcher class to be exposed at
all (and would prefer to make it totally private, so exposing it would
be against that goal); though people are already 'hacking' this kind of
functionality in, so it might be the best we can get at the current time?
Option #3
Do nothing.
Issues raised: everytime oslo.messaging changes this *mostly* internal
dispatcher API a project will have to make a new 'hack' to replace it
and hope that the semantics that it has 'hacked' in will continue to be
compatible with the various drivers in oslo.messaging. Not IMHO a
sustainable way to keep on working (and I'd be wary of doing this in a
project if I was the owner of one, because it's ummm, 'dirty').
My thoughts on what could work:
What I'd personally like to see is a mix of option #1 and #2, where we
have commitment from folks (besides myself, lol) to work on option #1
and we temporarily move forward with option #2 with a strict-statement
that the functionality we would be enabling will only exist for say a
single release (and then it will be removed).
Thoughts from others?
Doug
Thoughts?
[1]
https://github.com/openstack/mistral/blob/stable/mitaka/mistral/engine/rpc.py#L38-L88<https://github.com/openstack/mistral/blob/stable/mitaka/mistral/engine/rpc.py#L38-L88>
[2]
https://review.openstack.org/#/c/316578/<https://review.openstack.org/#/c/316578/>
Renat Akhmerov
@Nokia
__________________________________________________________________________
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 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
