I also find that smaller, job-oriented roles work well in scenarios like
this. It makes playbooks more maintainable and they read better when you
come back to them 3 months later.
On 24 February 2015 at 05:36, Timothy Gerla <t...@gerla.net> wrote:
> Hey Jack,
>
> The entire mission of Ansible is "simple IT automation", right? :)
>> Wherever possible, my preference would be for a single Ansible playbook to
>> handle the execution of a single high-level "goal"/"user request". If that
>> isn't the case, then one needs to somehow bundle those externally,
>> typically in a script. That requires the local "Ansible team" to decide on
>> and maintain knowledge in such a scripting language, and requires
>> implementing error checking and possibly error recovery in the scripting
>> language. Sure.. it isn't strictly necessary, but I would rather just call
>> a script "restart_system.bash" that makes a call to a single ansible
>> playbook instead of seeing the bash script make a call to 6 ansible
>> playbooks. What happens if the playbooks need to pass state or other data
>> between each other? Much cleaner if it occurs in a single call, no?
>>
>
> Sorry, I think I misunderstood your intent here. I definitely agree with a
> single playbook for a single high level user request. I jumped to the
> conclusion that you wanted to encode a bunch of different user requests in
> a single playbook.
>
> <snip>
>
>
>> I wrote some test roles to verify what you described would work:
>>
>>> ansible$ find roles/{web,app1,app2} -type f | sort
>>> roles/app1/startServer/tasks/main.yml
>>> roles/app1/stopServer/tasks/main.yml
>>> roles/app2/startServer/tasks/main.yml
>>> roles/app2/stopServer/tasks/main.yml
>>> roles/web/startMaintenance/tasks/main.yml
>>> roles/web/startServer/tasks/main.yml
>>> roles/web/stopMaintenance/tasks/main.yml
>>> roles/web/stopServer/tasks/main.yml
>>>
>> All of those files have what amounts to the the following code:
>>
>>> ansible$ cat roles/web/startMaintenance/tasks/main.yml
>>> ---
>>> - name: Run first task for startMaintenance
>>> debug: msg="Doing first task"
>>> - name: Run second task for startMaintenance
>>> debug: msg="Doing second task"
>>>
>> Each role gets a playbook for testing and when separate execution happens
>> to be needed:
>>
>>> ansible$ find playbooks/test/ -type f | grep -v restart | sort
>>> playbooks/test/app1_startServer.yml
>>> playbooks/test/app1_stopServer.yml
>>> playbooks/test/app2_startServer.yml
>>> playbooks/test/app2_stopServer.yml
>>> playbooks/test/web_startMaintenance.yml
>>> playbooks/test/web_stopMaintenance.yml
>>>
>> Each of those has some trivial, essentially identical code:
>>
>>> ansible$ cat playbooks/test/web_startMaintenance.yml
>>> ---
>>> - hosts: 127.0.0.1 # Imagine 'web'
>>> connection: local
>>>
>>> roles:
>>> - web/startMaintenance
>>>
>> Finally.. the restart playbook:
>>
>>> ansible$ find playbooks/test/ -type f | grep restart
>>> playbooks/test/restart_system.yml
>>> ansible$ cat playbooks/test/restart_system.yml
>>> ---
>>> - include: web_startMaintenance.yml
>>> - include: app1_stopServer.yml
>>> - include: app2_stopServer.yml
>>> - include: app2_startServer.yml
>>> - include: app1_startServer.yml
>>> - include: web_stopMaintenance.yml
>>>
>> Is there something about the way restart_system.yml is written above that
>> makes it "not Ansible-style" or that should be expected to lead to
>> problems? Thanks again.
>>
>>
> I would probably structure this a little bit differently, going back a
> little bit on what I said above about a single playbook per user request.
> This might actually be a really good use case for tags.
>
> playbooks/test/restart_system.yml:
>
> ---
> - hosts: 127.0.0.1
> connection: local
>
> roles:
> - { role: web/startMaintenance, tags: ['web'] }
> - { role: app1/stopServer, tags: ['app1'] }
> - { role: app2/stopServer, tags: ['app2'] }
> - { role: app1/startServer, tags: ['app1'] }
> - { role: app2/startServer, tags: ['app2'] }
> - { role: web/stopMaintenance, tags: ['web'] }
>
> Now you can invoke it with:
>
> ansible-playbook restart_system.yml --tags app1
>
> ...to only restart app1, or without tags to restart everything. (Maybe the
> web start/stop should be untagged, so it runs every time--not sure. Depends
> on your app.)
>
> This way you lose the intermediary playbooks, and end up with a single
> playbook to do all of your restart tasks.
>
> If app1 and app2 roles are really close together, maybe you could
> parameterize them, too:
>
> - { role: genericApp/stopServer, appName: "app1", tags: ["app1"] }
>
> -Tim
>
>
> --
> 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 ansible-project+unsubscr...@googlegroups.com.
> To post to this group, send email to ansible-project@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/ansible-project/CAH4wdVX2Dfh3he3u%3Dza1heytT9Hy6shsDGawDQ6GS7RTTbnT5Q%40mail.gmail.com
> <https://groups.google.com/d/msgid/ansible-project/CAH4wdVX2Dfh3he3u%3Dza1heytT9Hy6shsDGawDQ6GS7RTTbnT5Q%40mail.gmail.com?utm_medium=email&utm_source=footer>
> .
>
> For more options, visit https://groups.google.com/d/optout.
>
--
Tom Bamford
*@Planet*
ATPLANET (Pty) Ltd
atpla.net
Cell: +27 (0)79-095-7112
Fax: +27 (0)86-599-1310
--
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 ansible-project+unsubscr...@googlegroups.com.
To post to this group, send email to ansible-project@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/ansible-project/CAAnNz0No%2BVmc%2Badu3RmruhaZ8PZGPdhPXMaFDUXo-anxQXu1pA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
