On Monday, February 23, 2015 at 10:37:20 PM UTC-5, Timothy Gerla 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'] }
>
> This is a fine refactor of my demo code, but the real production code
can't do this because app1 is on "app1 server cluster" and app2 is on "app2
server cluster", etc You need a separate play for each call so that you can
use the "hosts" field to indicate which server set it is being applied to.
Right?
> Now you can invoke it with:
>
> ansible-playbook restart_system.yml --tags app1
>
> Thanks for pointing this out.
...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.
>
> I don't dislike the intermediary playbooks, since they can be used by
themselves and more easily composed together.
> If app1 and app2 roles are really close together, maybe you could
> parameterize them, too:
>
> - { role: genericApp/stopServer, appName: "app1", tags: ["app1"] }
>
> I will try to find an appropriate place to use this technique. Thanks!
> -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 [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/ee762320-b777-4d39-8c64-d1baf247034a%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
