I’m trying to make a general “mysql populate / dump” script, but using defined by group_vars/all and possibly overriden by host_vars.
These vars exist when the tasks defined within roles run, but do not appear to be defined at the playbook level.
Am I going nuts? Might be a separate question! So, the playbook looks like this:
“These vars exist when the tasks defined within roles run, but do not appear to be defined at the playbook level.”
Inventory variables can be different for each of your tasks. It is 100% normal and expected that we can’t print a task header that says x=52 when there are 500 systems
and some of them are x=11 and some are x=52 and some are x=59. If you do not give a name attribute to a task it will use the action line, so if this concerns you, just add a name
for your task.
Run with “-v” and you will see what is going on.
Sorry, I see I wasn’t very clear.
What I mean is, the vars such as store_db_name exist in other playbooks (e.g: common/tasks/main.yml) - but do not exist at the top level.
What I see with the above example is the mysql/tasks/log.yml receives “$db_name” as it’s variable. That’s the content. Not the name. db_name is not being set. I hope that’s clearer…
So. I create another playbook, idea being:
That too resulted in the same.
At (3) I still see ‘db_name’ not as the result of $store_db_name but as $db_name. Does’t appear to be set.
Incidentally, the name of the task does print just fine if I structure things this way, which indicates $store_db_name is defined. To me, it appears as if include isn’t resolving existing references. If I set db_name to a literal, that is fine, that gets passed through. Only existing vars look like they are missed out.
N
Impossible to help without seeing your playbooks.
Gist perhaps?
Funny you should ask. I just went downstairs to do just that 
Ignore me for a moment. It may be working and I was looking at some bad output (from me).
Please don’t spent time on this! I’ll post my results, but I think I did something stupid…!
Turns out I had some mis-spelled var names. It works just fine. Both at top level and if I use secondary.
Nothing to see here!
Thanks for taking the time.
Sure thing, if you are running 1.3 devel code, there’s a nice feature (which we are going to turn on by default soon) that will raise errors when variables are undefined rather than leaving as is untemplated.
I originally thought we should remain compatible here, but honestly, can’t think of many cases where it should be the other way! Further, it’s easy to reconfigure if you want the other behavior.
That sounds like a great idea. Bring it on!