Dmitry Tantsur wrote:
On 05/03/2016 11:24 PM, Joshua Harlow wrote:
Howdy folks,
So I meet up with *some* of the mistral folks during friday last week at
the summit and I was wondering if we as a group can find a path to help
that project move forward in their desire to have some kind of process
than ack (vs the existing ack then process) in there usage of the
messaging layer.
I got to learn that the following exists in mistral (sad-face):
https://github.com/openstack/mistral/blob/master/mistral/engine/rpc.py#L38
And it got me thinking about how/if we can as a group possibly allow a
variant of https://review.openstack.org/#/c/229186/ to get worked on and
merged in and release so that the above 'hack' can be removed.
Hey, lemme weigh in from ironic-inspector PoV.
As you maybe remember, we also need a queue with possibility of both
ways of ack'ing for our HA work. So something like this patch doesn't
seem to help us at all. We'll probably have to cargo-cult the mistral
approach.
U seem to be thinking about the queue as an implementation vs thinking
about what API do u really need and then say backing that API by a queue
(if u so want to).
Thus where https://review.openstack.org/#/c/260246/ comes into play here
because it thinks about the API first and the impl second (and if u
really want 2 impls, well they are at
https://github.com/openstack/taskflow/tree/master/taskflow/jobs/backends
but I'm avoiding trying to bring those into the picture, because the
top-level API seems unclear here still).
I guess it goes back to the 'why are people trying to use a message
queue as a work queue' when the semantics of these are different (and
let's not get into why we use a message queue as an RPC layer while we
are at it, ha).
Is it possible to have a manual ack feature? I.e. for the handler to
choose when to ack.
I also would like to come to some kind of understanding that we also
(mistral folks would hopefully help here) would remove this kind of
change in the future as the longer term goal (of something like
https://review.openstack.org/#/c/260246/) would progress.
Thoughts from folks (mistral and oslo)?
Anyway we can create a solution that works in the short term (allowing
for that hack to be removed) and working toward the longer term goal?
-Josh
__________________________________________________________________________
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
__________________________________________________________________________
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
