Open Stack

On Mon, 2016-02-01 at 15:17 +0600, Renat Akhmerov wrote:
> Hi,
> 
> 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.
> 
> API
> 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).
> 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.

Although this thread has gone in many directions I think the primary
need we are looking for with Mistral is to help us expose deployment
workflows to both a CLI and UI. Some of the workflows do have state
(say a set of templates, and parameters) which we would like to be able
to manage equally well regardless of which tool the end user chooses
(again CLI or UI). The benefit of Mistral is that as an in-cloud
generic workflow tool it sits nicely within the TripleO stack, allows
us to customize what we need without writing boilerplate code we would
prefer not to maintain. And because it is generic it can do things like
call Heat, or be called by Heat all natively.

> 
> Mistral & Ansible comparison
> IMO, it’s not 100% correct to compare Mistral with Ansible for a
> number of reasons:
> 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).
> 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.
> 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.
> 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.
> 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.
> 
> 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.
> 
> Thanks

Thanks for this summary. Lots of good points in here and I think
perhaps it would be nice to see some side by side examples of trying to
use the tools for various things. Highlighting where Mistral and or
Ansible excel in certain areas. The biggest missing feature we'd need
for Ansible to be a solution for us would be an API (aka something like
Tower). Without that or something equivalent (like a Mistral or custom
generic API on top of Ansible) I'm not sure we could consider Ansible
as a solution for our needs at the moment.

Dan

> 
> Will keep reading...
> 
> Renat Akhmerov
> @ Mirantis Inc.
> 
> _____________________________________________________________________
> _____
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubs
> cribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev