Open Stack

> On 02 Feb 2016, at 03:55, Dan Prince <dprince at redhat.com> wrote:
> 
> 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.

Yeah, makes perfect sense to me. It’s one of the cool things that workflows
in general provide: ability to build a template of a process where steps could
be reimplemented in different ways.

Renat Akhmerov
@ Mirantis Inc.