[openstack-dev] [Mistral] Query on creating multiple resources
zbitter at redhat.com
Tue Dec 9 20:20:15 UTC 2014
On 09/12/14 03:48, Renat Akhmerov wrote:
> 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
- 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.
More information about the OpenStack-dev