Open Stack

On 18 Mar 2014, at 01:32, Joshua Harlow <harlowja at yahoo-inc.com> wrote:
> To further this lets continue working on https://etherpad.openstack.org/p/taskflow-mistral and see if we can align somehow

Sure.

> (I hope it's not to late to do this,

Never late IMO.

> seeing that there appears to be a lot of resistance from the mistral community to change.

Could you please let us know how you made this conclusion? I’m frankly surprised.. It’s not just my curiosity or something, I want to keep improving in what I’m doing.


Generally, just to clarify the situation let me provide our vision of what we’re doing at the very high level.

As mentioned many times, we’re still building a PoC. Yes, it turned out to take longer which is totally fine since we’ve done a lot of research, lots of coding exercises, talks, discussions with our customers. We’ve involved several new contributors from two different companies, they have their requirements and use cases too. We’ve gathered a lot of specific requirements to what should be a workflow engine. This all was the exact intention of that phase of the project: understand better what we should build. If you look at Mistral list of blueprints you’ll see around 40 of them where 80-90% of them come from real needs of real projects. And not everything is still captured in BPs because something is still not shaped well enough in our minds.

Thought #1: In POC we’ve been concentrating on use cases and requirements. Implementation has been secondary.

TaskFlow or anything else just hasn’t mattered a lot so far. But, at the same time, I want to remind that in December we tried to use TaskFlow to implement the very basic functionality in Mistral (only dependency based model). Honestly, we failed to produce a result that we would be satisfied with since TaskFlow lacked, for example, the ability to run tasks in an asynchronous manner. This was not a problem at all, this is the real world. So I created a BP to address that problem in TaskFlow ([0]). So we decided to proceed with it with an intent to rejoin later.
And may be even the most important reason not to use TaskFlow was that we did want to have a clear research. We found that less productive to try to build a project around an existing library than concentrating on use cases and high-level requirements. From my experience, it never works well since in your thinking you always stick to limitations of that lib and assumptions made in it.

So we actually talked to people a lot (including Josh) and provided this reasoning when this question raised again. Reaction was nearly always positive and made a lot of sense to customers and developers.

Thought #2: A library shouldn't drive a project where it’s used.

Project needs should define the requirements to a library. Even being adopted in lots of places (this is apparently not true for TaskFlow right now which is fully understandable, a pretty young project as well) a library is just one of many tools used within a project. But not vice versa.

Thought #3. We 100% admit we’re not ready for incubation right now.

We prepared an incubation request already with most of the formal requirements met by the project. And even thought the interest to Mistral is serious (at least 5-6 projects intent to use it, one already started playing and prototyping with Mistral) we want to be honest with the community in that we’re not really ready for incubation since even our own solid understanding of core requirements and API/DSL is only on its way. This is just one more argument that spending significant time on thinking how to fit TaskFlow into our unstable Mistral vision is not affordable for us at the moment. Despite of that, last week we started spending that time after Josh started bombing us with his concerns :).


If that’s all harsh, sorry. We’re interested in keeping in touch with Josh and others.

[0] https://blueprints.launchpad.net/taskflow/+spec/async-tasks

Renat Akhmerov
@ Mirantis Inc.

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