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 <[email protected]> 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 [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/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 [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/CAAnNz0No%2BVmc%2Badu3RmruhaZ8PZGPdhPXMaFDUXo-anxQXu1pA%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
