I believe I've got similar usecase except my starting point is different. I found that parametrized includes do exactly what I need so there's no issue with roles vs task includes. However while roles have a defined search path and allow for central repo of roles, includes can only be in the same directory or referenced using full/relative path which doesn't allow for portability.
Here's one of my examples: I'd like to configure certain network interface on the machine, however I would like to locate it based on it's MAC address and then do the rest of config based on that. So it's like a "function" in typical programming language - some inpts are given with some outputs expected. Making it a role works only to a point - that means I have to either use "dependency" from other roles to invoke it mid-play or use it directly from top-level play. With "include" statement I can use it inline but then I have to sacrifice portability and provide full path. For some of my other usecases building modules is impractical since it has to operate on several machines - thus using playbooks is more natural. To put it short - we already have "library" and "roles_path" for dealing with central location of those items. Can we also have "includes_path"? This should close the gap that currently exists due to roles being allowed only at top-level playbooks. On Friday, November 7, 2014 7:19:02 AM UTC-7, Michael DeHaan wrote: > > There will not be a task that applies roles, the "role" directive is for > 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/8af06f91-ab52-4bcb-a5ad-f40492ee4911%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
