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.
For more options, visit https://groups.google.com/d/optout.

Reply via email to