I have to agree with Brian – sounds like you are not breaking your problem down into simple enough parts.
The problem with Ansible (and other similar config management / state management tools) is that most people (well, at least me) come in thinking one way about their requirements which isn’t immediately compatible with how the tool was designed and/or works. You have to learn to think about your problems in terms of Ansible (or whatever tool you’re using). In this case, Ansible is stupidly simple on purpose. However, I’ve been beating my head against it for about 6 months now and am just starting to really ‘get it’. And most of that was me learning how to simplify what I needed to do into smaller and smaller chunks which made sense for Ansible and then how to relate those chunks together. One of the big things was determining when and where I did certain things within Ansible. You can put things in playbooks or roles or both, but not all will necessarily be good for you. For example I have a role for my NTP configuration. I then have this role applied to all hosts in my top level play list. However, I then ran into a hurdle as all machines need NTP, but there is one machine that must be an NTP server. I first worked on this with having different roles (ntp-client vs ntp-server) but found for my needs that a single ‘ntp’ role would suffice and within that role I then choose one of two different templates (client vs server) based upon whether or not the host was in the ‘ntp server‘ host group. I do want to point out that I could have used two different roles but I decided against that for reasons that make sense within my hosting environment. My point is, I had many options on how to put the Ansible building blocks together and it took me a while to figure out the best way to put them together for my needs. There was a lot of trial and error. But I’ve finally got there. Another thing I did was to use the ‘group_by’ functionality to build host groups on the fly. Then I use those groupings to determine when to apply different roles or even different parts of specific roles. So, originally I just had roles with a single ‘tasks/main.yml’. And I tried to keep it that way. But after working with Ansible for a while and reviewing what I was trying to do, I now have roles with lots of task files that get included within tasks/main.yml. So a lot of my roles use a lot of ‘include/when’ patterns based around groupings I’ve built on the fly via ‘group_by’. So, TL;DR – keep pounding on it, keep trying different code arrangements, keep trying to break your requirements into smaller and simpler parts. Also, you have to figure out how best to put all the pieces together. Such as some people don’t use role dependencies, but some people love them. Eventually you’ll get it. And I would say that as you use Ansible expect that you will end up re-writing your entire Ansible code base a couple of times until you find a layout that works best for you. Thx Gopher. From: [email protected] [mailto:[email protected]] On Behalf Of Brian Coca Sent: Tuesday, June 03, 2014 8:25 AM To: [email protected] Subject: Re: [ansible-project] Re: Are Roles enough? roles are there to make reusable units of non trivial set of tasks, sometimes its just easier to create a simple tasklist and use include:. If it is becoming 'painful' its a sign of trying to put square peg in round hole. Ansible is designed to be simple, also it is very flexible and can be used in many different ways. It leaves organization up to you but sometimes this becomes an issue, specially if coming from other tools from which you got into the habit of complexity. I recommend taking a step back at this point, go back to you goal and think of simpler approaches. for the original poster, you can use roles == features or even a 'wrapper role' that uses the feature roles as dependencies. I generally equate 'machine roles' == groups and use plays to group 'feature roles'. -- Brian Coca Stultorum infinitus est numerus 0110000101110010011001010110111000100111011101000010000001111001011011110111010100100000011100110110110101100001011100100111010000100001 Pedo mellon a minno -- 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]<mailto:[email protected]>. To post to this group, send email to [email protected]<mailto:[email protected]>. To view this discussion on the web visit https://groups.google.com/d/msgid/ansible-project/CADn%2BHsyF_rJST5VOmc4xSUg9As86Ls3iWnhAa2f_t4CEXLGSxw%40mail.gmail.com<https://groups.google.com/d/msgid/ansible-project/CADn%2BHsyF_rJST5VOmc4xSUg9As86Ls3iWnhAa2f_t4CEXLGSxw%40mail.gmail.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/BFD6B7398AEB474A9A28B39B9B5D00CB73C0ADCE%40SRAexMBX01.sra.com. For more options, visit https://groups.google.com/d/optout.
