Open Stack

On 09/12/14 03:48, Renat Akhmerov wrote:
> Hey,
>
> I think it’s a question of what the final goal is. For just creating security groups as a resource I think Georgy and Zane are right, just use Heat. If the goal is to try Mistral or have this simple workflow as part of more complex then it’s totally fine to use Mistral. Sorry, I’m probably biased because Mistral is our baby :). Anyway, Nikolay has already answered the question technically, this “for-each” feature will be available officially in about 2 weeks.

:)

They're not mutually exclusive, of course, and to clarify I wasn't 
suggesting replacing Mistral with Heat, I was suggesting replacing a 
bunch of 'create security group' steps in a larger workflow with a 
single 'create stack' step.

In general, though:
- When you are just trying to get to a particular end state and it 
doesn't matter how you get there, Heat is a good solution.
- When you need to carry out a particular series of steps, and it is the 
steps that are well-defined, not the end state, then Mistral is a good 
solution.
- When you have a well-defined end state but some steps need to be done 
in a particular way that isn't supported by Heat, then Mistral can be a 
solution (it's not a _good_ solution, but that isn't a criticism because 
it isn't Mistral's job to make up for deficiencies in Heat).
- Both services are _highly_ complementary. For example, let's say you 
have a batch job to run regularly: you want to provision a server, do 
some work on it, and then remove the server when the work is complete. 
(An example that a lot of people will be doing pretty regularly might be 
building a custom VM image and uploading it to Glance.) This is a 
classic example of a workflow, and you should use Mistral to implement 
it. Now let's say that rather than just a single server you have a 
complex group of resources that need to be set up prior to running the 
job. You could encode all of the steps required to correctly set up and 
tear down all of those resources in the Mistral workflow, but that would 
be a mistake. While the overall process is still a workflow, the desired 
state after creating all of the resources but before running the job is 
known, and it doesn't matter how you get there. Therefore it's better to 
define the resources in a Heat template: unless you are doing something 
really weird it will Just Work(TM) for creating them all in the right 
order with optimal parallelisation, it knows how to delete them 
afterwards too without having to write it again backwards, and you can 
easily test it in isolation from the rest of the workflow. So you would 
replace the steps in the workflow that create and delete the server with 
steps that create and delete a stack.

>> Create VM workflow was a demo example. Mistral potentially can be used by Heat or other orchestration tools to do actual interaction with API, but for user it might be easier to use Heat functionality.
>
> I kind of disagree with that statement. Mistral can be used by whoever finds its useful for their needs. Standard “create_instance” workflow (which is in “resources/workflows/create_instance.yaml”) is not so a demo example as well. It does a lot of good stuff you may really need in your case (e.g. retry policies). Even though it’s true that it has some limitations we’re aware of. For example, when it comes to configuring a network for newly created instance it’s now missing network related parameters to be able to alter behavior.

I agree that it's unlikely that Heat should replace Mistral in many of 
the Mistral demo scenarios. I do think you could make a strong argument 
that Heat should replace *Nova* in many of those scenarios though.

cheers,
Zane.