[openstack-dev] Fwd: [oslo][mistral] Saga of process than ack and where can we go from here...

Dmitriy Ukhlov dukhlov at mirantis.com
Tue May 3 21:47:15 UTC 2016


Hi Joshua.

I think than Mistral have already fast solution - they customised oslo.messaging rpc to achieve ack-after-process in Mistral code base

About solution in oslo.messaging code base… I plan to write spec for new oslo.messaging driver interface soon as was agreed during design session (we need transport specific interface, not user API specific as we have now)
Also we could start work on new User API need by Mistral meanwhile.

> Begin forwarded message:
> 
> From: Joshua Harlow <harlowja at fastmail.com>
> Subject: [openstack-dev] [oslo][mistral] Saga of process than ack and where can we go from here...
> Date: May 4, 2016 at 12:24:13 AM GMT+3
> To: "OpenStack Development Mailing List (not for usage questions)" <openstack-dev at lists.openstack.org>
> Reply-To: "OpenStack Development Mailing List \(not for usage questions\)" <openstack-dev at lists.openstack.org>
> 
> 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.
> 
> 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-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20160504/88729d8d/attachment.html>


More information about the OpenStack-dev mailing list