On 31 окт. 2013 г., at 2:37, Clint Byrum <cl...@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 
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.


OpenStack-dev mailing list

Reply via email to