src search logic

Seems like there should be a best practice for this, but I don't know it even after looking at the source.

I'm trying to structure my playbooks, tasks and configurations in an infrastructure repository. A bunch of my tasks include other more generic web server tasks and configurations, and I'd like to keep all of these in a single directory. Theoretically, if I then want to switch web servers, I need only tweak the proxy/CGI/directory-serving config files in a single location, rerun my various configuration plays and I'm mostly migrated.

I'm running into some issues with the template module, though. In particular, if I have webapp/war.yml which includes ../include/lighttpd/proxy.yml, and ../include/lighttpd/proxy.yml accesses proxy.j2 as the src of a template, that src is searched for relative to webapp/, the directory containing the first task.

Would it make sense to make this file search logic slightly more verbose? Check for src files as absolute paths and relative to the original play/task, but also check for them relative to the task from which they were run? So in the above example, my src wouldn't just be checked for in webapp/, but in webapp/../include/lighttpd as well. Seems similar to the problem of task inclusion (which appears to have been solved, thanks for that) so perhaps these could use the same logic?

Or is there some better way of doing this that I'm missing? Would be nice to quarantine all my web server configs to a single set of tasks/templates in one directory that are referenced from many other places, then a migration would be just a matter of rewriting everything in that directory and maybe changing some task names everywhere else.

Thanks.

So we have an open ticket to make the path_dwim logic smarter with playbooks at different depths. Stay tuned...

-- Michael

I assume you mean:

https://github.com/ansible/ansible/issues/1293

I saw that this was closed, but it still doesn't solve my issue in latest devel. It still searches for the file relative to the initiating play, not to the play included from the initial play.

Thanks.

Yes, it's not done in the latest devel, in consideration for 1.0

Patience please. Or large sums of money.

No worries, I just assumed that the ticket's closure meant that it was supposed to be done, so wanted to report that it still wasn't working like I'd expect.

Thanks.

Various comments are in #1615