David, I'm coming from a similar place in terms of seeing things as roles with features and I'm also just getting started with ansible.
I made a common role considering it as 'included for all roles and applied conditionally'. Tasks are included based on group membership, or host in inventory. I organize the files dir into folders for each task, which each represent "features". You can account for configuration differences within tasks based on inventory as well. Based on ideas in this thread I'm considering breaking as much as I can into "feature" roles, which are added to "functional" roles, and only leaving what is truly common (ie. firewall rules, etc). On Tuesday, June 3, 2014 12:38:45 AM UTC-4, David Carmean wrote: > > > I was happy to see "roles" when I came back to Ansible after a few months, > but i've been struggling with how to apply them. I think this is partly > because of cognitive dissonance between my mental model and the current > terminology. > > In my mind, any particular role that a server may fill (and it may fill > more than one), in turn requires one or more "features" or "feature-sets" > in order to be able to fulfill that role. In other words, I think of a > heirarchy that looks like this; > > * appstack_X > ** server_n > *** role_a > **** feature_A > **** feature_E > **** feature_O > *** role_b > **** feature_A > **** feature_B > **** feature_G > > Anyone else gone through this thought process,or organize their configs > like this? > > > > -- 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/7c75c7aa-b624-4ba5-b7ca-322cb8893e31%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
