
<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class="">Hi,</div><div class=""><br class=""></div><div class="">I’ve read only part of letters in this huge interesting thread so far but I’d like to try to jump in and give some comments.</div><div class=""><br class=""></div><div class=""><b class="">API</b></div><div class="">I personally don’t support using Mistral API as is. Maybe you came to agreement already about that, don’t know. I think that API should reflect user needs in specific functionality in the most suitable and natural way and provide an abstraction over implementation details such as a backend technology (that can easily change).</div><div class="">If there are processes though on the backend that need to be HA, stateful and you need to have a fine-grained control over them (stop, resume, etc.) and monitoring of all the state then I’d recommend consider Mistral for sure.</div><div class=""><br class=""></div><div class=""><b class="">Mistral & Ansible comparison</b></div><div class="">IMO, it’s not 100% correct to compare Mistral with Ansible for a number of reasons:</div><div class=""><ul class="MailOutline"><li class="">Ansible is a less general technology, it’s sharpened for configuration management and deployment tasks hence it has lots and lots of specific things in the language (mostly properties).</li><li class="">Mistral workflow language is not 100% replica of Ansible Playbooks, there are significant differences in concepts, data model, execution model (e.g. tasks always run sequentially in Ansible whereas in Mistral they can be parallelized in a number of ways). Mistral provides graph-based workflows.</li><li class="">Mistral in its core assumes pluggability for different workflow types each one of them can have absolutely different semantics. For example, currently it has workflow types “direct” (default) and “reverse” that works according to a different logic. It’s pretty easy to extend it with something else, for example, task priority based workflow.</li><li class="">As I mentioned before Mistral is mostly about state management: all workflows, subworkflows, tasks and actions have state observable through API. From this standpoint, it is more like taskflow with an important difference that Mistral is a service. It provides functionality to manage life cycle of workflows such as stop, resume, recover from errors. It also provide various policies that can be applied to workflow tasks such as “retry”, “timeout”, “pause-before” etc.</li><li class="">As far as I understand there’s a serious difference in Ansible and Mistral architecture. Mistral is naturally based on asynchronous processing model that makes it possible to have asynchronous actions w/o having to use polls and allows engine to be scalable naturally. In other words, each engine instance is stateless.</li></ul><div class=""><br class=""></div></div><div class="">As far as languages, it requires significant work on comparison. In a nutshell, Ansible has a lot of stuff that’s missing in Mistral and vice versa. For example, Ansible has lots of nice things like various looping capabilites expressed as “with_XXX” whereas Mistral can only iterate over lists.</div><div class=""><br class=""></div><div class="">Thanks</div><div class=""><br class=""></div><div class="">Will keep reading...</div><br class=""><div class="">

<div class="">Renat Akhmerov</div><div class="">@ Mirantis Inc.</div><div class=""><br class=""></div></div></body></html>