Just a note also: Taskflow's in a way is event-driven also, a workflow goes through various events and those events cause further actions (state-transitions, notifications, forward-progress).
I fully expect the https://review.openstack.org/#/c/63155 (yes not oslo.messaging, but someday when that library exists) to be more in your idea of event-driven. To me u can model an event-driven system using an executor type (but not so much the other-way around); but perhaps it is possible and I can't think of it right now. In fact if u look at what guido is doing with tulip [1] u can see a way to connect events to executors/futures to events (slightly similar to taskflows engine+futures). I'd really like mistral to get back on using taskflow and helping converge instead of diverge, so lets make it happen :-) -Josh [1] http://www.python.org/dev/peps/pep-3156/ From: Renat Akhmerov <rakhme...@mirantis.com<mailto:rakhme...@mirantis.com>> Reply-To: "OpenStack Development Mailing List (not for usage questions)" <openstack-dev@lists.openstack.org<mailto:openstack-dev@lists.openstack.org>> Date: Monday, January 27, 2014 at 12:31 PM To: "OpenStack Development Mailing List (not for usage questions)" <openstack-dev@lists.openstack.org<mailto:openstack-dev@lists.openstack.org>> Subject: Re: [openstack-dev] Mistral + taskflow mini-meetup Josh, thanks for sharing this with the community. Just a couple of words as an addition to that.. The driver for this conversation is that TaskFlow library and Mistral service in many ways do similar things: task processing combined somehow (flow or workflow). However, there’s a number of differences in approaches that the two technologies follow. Initially, when Mistral’s development phase started about a couple of months ago the team was willing to use TaskFlow at implementation level. Basically, we can potentially represent Mistral tasks as TaskFlow tasks and use TaskFlow API to run them. One of the problems though is that TaskFlow tasks are basically python methods and hence run synchronously (once we get out of the method the task is considered finished) whereas Mistral is primarily designed to run asynchronous tasks (send a signal to an external system and start waiting for a result which may arrive minutes or hours later. Mistral is more like event-driven system versus traditional executor architecture. So now Mistral PoC is not using TaskFlow but moving forward we we’d like to try to marry these two technologies to be more aligned in terms of APIs and feature sets. Renat Akhmerov @ Mirantis Inc. On 27 Jan 2014, at 13:21, Joshua Harlow <harlo...@yahoo-inc.com<mailto:harlo...@yahoo-inc.com>> wrote: Hi all, In order to encourage further discussion off IRC and more in public I'd like to share a etherpad that was worked on during a 'meetup' with some of the mistral folks and me. https://etherpad.openstack.org/p/taskflow-mistral-jan-meetup It was more of a (mini) in-person meetup but I thought I'd be good to gather some feedback there and let the more general audience see this and ask any questions/feedback/other... Some of the key distinctions between taskflow/mistral we talked about and as well other various DSL aspects and some possible action items. Feel free to ask questions, -Josh _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org<mailto:OpenStack-dev@lists.openstack.org> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
_______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
