Exporting variables as host facts

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:

     https://github.com/ansible-provisioning/ansible-provisioning

How does it work:

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.

This is very interesting. I actually stumbled upon a problem yesterday
that this module would have fixed :slight_smile:

.a.

I think naming is important and I really don't like 'set_global' and 'set_local' as names. Not that I am emotionally attached to 'export' either.

Can we do better ?

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?

Why not just use local vs global ?

It can't be more explicit (as we like it) without the redundancy.

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?

Actually, I’d probably just go with “set” :slight_smile:

Less is more !

So we go for "set" and "global", right ?

I'll do the PR tomorrow, need sleep now...

Sure!

(s and g! No, wait!)

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 :slight_smile:

"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.

.a.

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...

don’t think there’s much you can set in any system that is not a variable.

Jinja2 has a set keyword, for instance.

Hi,

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 }}”

Greetings,
gw

You can already use the proposed set with Jinja2, there is no need for a new eval.

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 !