Hundred percent agree with all said by Zane. Renat Akhmerov @ Mirantis Inc.
> On 10 Dec 2014, at 02:20, Zane Bitter <[email protected]> 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 > [email protected] > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev _______________________________________________ OpenStack-dev mailing list [email protected] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
