Ok, in the old days Ansible would have all variables defined in a playbook in the global scope. At some point this was deemed non-intentional and we limited it to the local scope of the play instead.
But that means that prompt_vars too are bound only to the local scope, and one cannot easily define variables in a play to the global scope, unless you mock around with command, echo and register.
Some people have asked for such a 'variable' module before, I called mine 'export'. The shortest module ever !
You can find it in the ansible-provisioning repository at:
Can you send me a pull request and maybe rename this to “set_global” ?
I think we also want some nice “set_local” too, though I also agree this is basically register, folks have been wanting a way to save {{ foo.upper() }} and things like that in 1.2 to variables, occasionally.
Asking this seriously, better how? I don’t really like “export” (that already means something in Unix land, and lots of other things elsewhere), and it does set a global, doesn’t it?
Sorry, as I mentioned earlier my brain was recovering from being sick this weekend. Just clicked that you are setting locally because you are returning facts.
That’s great, let’s just call it ‘set_local’ then?
Thanks! Sleep is good. Except when I design systems management software in my sleep. I’m getting close to having a working sleep-mode Python compiler. You don’t want to know
"set" is a bit vague IMHO, a newbie would wonder *what* is actually
set. What about "vars"? It recalls the "vars:" section, it should be
more straightforward. especially for new users.
Problem with vars is that people may think they can add variables just like the "vars:" section in the playbook, while this is in fact an action in a task. Becomes very confusing very quickly...
What about “register”? And maybe making the module behave as close to the other meaning of “register” keyword, that it would not cause too many confusions?
Otherwise “set” makes sense.
A weird idea that probably shouldn’t be implemented would also be to create a module to just execute arbitrary Jinja2 code, eg “eval” or “jinja2”: eval: “{{ set foo = bar }}”
Namespace conflict. How would Ansible make the distinction between:
- register: foo=bar
- user: name="foo"
register: bar
It reads like:
- action: register foo=bar
- action: user name="foo"
register: bar
That's why we have to be very careful not to name modules after reserved words, and not introduce new statements named after module names. 'user' in itself is already quite confusing as it's used in plays and as a module name in tasks.
As a tutor I always advise to use "action:" and not "module:".
Go for explicit statements, not brevity !
