Open Stack

On 31 окт. 2013 г., at 2:37, Clint Byrum <clint at fewbar.com> wrote:

> My point
> is really that we should not care how serialization happens, we should
> just express the work-flow, and let the underlying mechanisms distribute
> and manage it as it is completed.


Sounds reasonable.

In this context, you may want to look at Mistral project we recently started. We just published a kind of a high-level description of the use case that is relevant for the problem that is being discussed here. It’s called Cloud Environment Deployment and you can find it at https://wiki.openstack.org/wiki/Mistral/Cloud_Environment_Deployment_details. We think it can be a very important application for Mistral. Any kinds of locking mechanism, imho, should be avoiding at all system levels unless it’s absolutely required for algorithm complexity reasons (when there’s no other way). So If we can represent what Heat does in its internals as a set of related tasks we can offload dependencies resolution to a system like Mistral that would do everything in a distributed manner.

Another interesting feature we’re planning to implement is data flow. That is, some state (sort of a context) associated with a workflow travels between nodes in a task graph so there’s no need to worry about a shared state in many cases. Data transfer itself is supposed to work on top of some HA transport itself (like rabbit) so it shouldn’t be a challenge to implement it. Not 100% sure that it’s all applicable for solving this Heat task (pardon me), but it definitely could be considered as a possibility. Unfortunately, we’ve not described this feature very well yet (only some pictures and sketches not published anywhere), but we’ll do soon.

I don’t really want it to look like an ad, sorry if it does ( :) ). It would be cool if we could collaborate on this. Once you look at our ideas, you could provide your input on what else should be taken into account in Mistral design in order to address your problem well.

Renat


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