Open Stack

Hundred percent agree with all said by Zane.

Renat Akhmerov
@ Mirantis Inc.



> On 10 Dec 2014, at 02:20, Zane Bitter <zbitter at redhat.com> wrote:
> 
> 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.
> 
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev