Hi Jeff, I can only agree with Michael here - playbooks describe ordering of operations for a specific operational purpose and as far as I know role dependencies will not get you there in the scenario you describe.
The way I usually do this is to think of splitting my roles into two. You generally need two paths through your collections of tasks. The following broad groups can usually be combined: 1) install / start / simple reconfiguration 2) stop / remove If you're using roles currently as a "this is what should be present in my working application" then you've currently got the first one sorted. For example, I have a global playbook that describes the current state of my entire system that I want to enforce. I use that for the first purpose and it works very well. I have specific playbooks for removals or stopping particular apps (with dependencies) or more complicated reconfigurations or upgrades. You may even want to have roles called "remove_foo" or so on but its generally easier to have this in a dedicated playbook unless its something that you're doing often or that can be easily parameterised between plays (eg remove_app name=foo, remove_app name=bar). Hope this helps. Cheers, Andrew On 27 March 2015 at 02:58, Jeff Sussna <[email protected]> wrote: > Let me try to better illustrate my question with a more concrete example. > Imagine an app Foo that has two tiers: Apache and MySQL. Each tier is a > role with start and stop tasks. These tasks are tagged appropriately. Foo > lists Apache and MySQL as its contained roles. > > Starting the app is as simple as "ansible-playbook Foo.yml --tags=start". > Stopping it is a matter of "ansible-playbook Foo.yml --tags=stop". > > The interesting part comes in because to start Foo, MySQL needs to start > first. To shut down Foo, Apache needs to stop first. Without a home-grown > hack, there doesn't appear to be any way to conditionally control the order > of role specifications. The hack is to specify the roles twice, in reverse > order, with an associated variable that the leaf-level start/stop tasks use > to decide whether to actually fire or not (yes, it's ugly :-). > > This doesn't seem like a weird use case to me, so I'm hoping there's a > more elegant solution that doesn't involve separate roles/playbooks for > every action type (start/stop/install/etc.). > > > > On Tuesday, March 24, 2015 at 3:29:16 PM UTC-5, Michael Peters wrote: >> >> I don't know if this helps, but I usually use roles for configuration >> management and use standalone playbooks for orchestration stuff. I've >> just found it easier to have more control if I centralize certain >> aspects (like say an application upgrade) in a single playbook instead >> of spread around in different roles. But roles are super useful for >> configuration management. >> >> Just my 2 pence... >> >> On Tue, Mar 24, 2015 at 4:22 PM, Jeff Sussna <[email protected]> >> wrote: >> > Dumb question re orchestrating the starting and stopping of tiered >> services >> > with ordering dependencies: >> > >> > Imagine tier A depends on tier B. To bring up the app, start B then A. >> To >> > bring it down, stop A then B. I can't figure out whether it's possible >> to >> > represent these relationships using roles without having to basically >> > duplicate things so there is an A-stop role, a A-start role, a B-stop >> role, >> > and a B-start role. Have gotten close to figuring it out using >> start/stop >> > tags, but can't model to opposite ordering dependencies between start >> and >> > stop. >> > >> > Anyone else come up with an efficient reusable way to model this use >> case? >> > >> > -- >> > You received this message because you are subscribed to the Google >> Groups >> > "Ansible Project" group. >> > To unsubscribe from this group and stop receiving emails from it, send >> an >> > email to [email protected]. >> > To post to this group, send email to [email protected]. >> > To view this discussion on the web visit >> > https://groups.google.com/d/msgid/ansible-project/ >> fee39d00-8c4f-4daf-b4eb-a02d5d4956ec%40googlegroups.com. >> > For more options, visit https://groups.google.com/d/optout. >> > -- > You received this message because you are subscribed to the Google Groups > "Ansible Project" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To post to this group, send email to [email protected]. > To view this discussion on the web visit > https://groups.google.com/d/msgid/ansible-project/cd45fec5-7fd0-4da3-8156-76ddd50013e9%40googlegroups.com > <https://groups.google.com/d/msgid/ansible-project/cd45fec5-7fd0-4da3-8156-76ddd50013e9%40googlegroups.com?utm_medium=email&utm_source=footer> > . > > For more options, visit https://groups.google.com/d/optout. > -- You received this message because you are subscribed to the Google Groups "Ansible Project" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/ansible-project/CAJj6K08zwuGqZrHGPEWOPG095wHhnEr3hZcPqMhhksHdU-OUxg%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
