It's cleaner to have the roles explicitly listed up in site.yml . Then site.yml defines the roles on each host group, and you avoid the issue with roles running twice when you explicitly define them that way.
You can still have 'states' as you define them just as typical roles, maybe with a README in there to explain it's a 'building block' role and needs further config to be usable (we name those roles base-nginx, base-elasticsearch, etc. when they don't have a valid config so will need to be tailored to do be functional). Having said all that, I do use roles/foo/meta/main.yml to 'autoload' dependencies sometimes; there are several of us working on this playbook so it can be helpful. Mind you, I've got several years of Puppet baggage so 'wiring' modules together is in my muscle memory, I'm not sure if that's the Ansible Way.. On 6 June 2014 22:35, Joost Cassee <[email protected]> wrote: > Hi Michael and others, > > It could be me explaining wrong, or I could be off the path, but let > me try again. My site playbook is basically only used to tie roles to > host groups. Those roles are specific for our infrastructure, e.g. > setting up our frontend server, backend server, etc. I call those > "profiles". The roles I call "states" are more like shareable > components: setting up Nginx, fail2ban, etc. The dependencies follow > the path: playbook -> profile role -> state roles (-> state roles). > > This feels quite natural to me, but I do run into the issues I > described. If this set-up is still too complex I am very interested to > hear about simplifications. > > Regards, > Joost > > 2014-06-06 14:25 GMT+02:00 Michael DeHaan <[email protected]>: >>> >>> Both profiles and states are roles, but I separate them into two roles >>> directories. I then use role dependencies between profiles and states (and >>> states and states). A playbook simply ties hosts to profile roles. >>> >>> A few thing I ran into: >>> * I needed to use a trick to make sure each state role is run only once. >>> See [1]. >> >> >> Please don't try to make ansible more complex than it actually is. I'm not >> even sure what a "profile" or "state role" is, and if I don't know, that's a >> problem with someone interpreting ansible to be WAAAAY more complicated than >> it should be. >> >> We're talking servers here, not programming. >> >> Simplify. Keep things easy. >> >> -- >> You received this message because you are subscribed to a topic in the >> Google Groups "Ansible Project" group. >> To unsubscribe from this topic, visit >> https://groups.google.com/d/topic/ansible-project/gqGkznqr-Ao/unsubscribe. >> To unsubscribe from this group and all its topics, 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/CA%2BnsWgzVizm5wQo9HwpBnx6asyMPwx7hC3YMvJLYh_ioSWQ8ow%40mail.gmail.com. >> >> For more options, visit https://groups.google.com/d/optout. > > > > -- > Joost Cassee > http://joost.cassee.net > > -- > 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/CAEQrH%2BeWJ-HLyeL_mKMgZj1dQW-DfAo1nRxauX-s4Wr2DkdGCA%40mail.gmail.com. > 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/CAK5eLPSH3DOBMjbBBGZbbtHLHCKVTP5qOmgqAnu6jh05%2BTorJg%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
