ansible_python_interpreter, variable scope, and bootstrapping

Archives Ansible Project
1

I find myself in a fairly unfortunate situation where I’m trying to prove Ansible’s versatility in adverse situations and coming up a bit short. Hopefully you can help.

I work with Solaris systems where I don’t have root access and don’t really have any kind of package manager available, so I have to improvise. I have a bootstrap playbook that connects to my remote Solaris box, downloads the Python 2.7 source code, and builds it in a prefix in my home directory using the shell module and gather_facts: false.

OK, now I want to set ansible_python_interpreter to point to the new Python install, so that the rest of my plays will work predictably. And I want to know what that prefix directory is throughout the rest of my plays as well. Of course, other people might run this Ansible play as well, so I can’t hardcode my username. And I might want to use the same scripts on other systems, say, OS X.

What all this comes down to is that I need to dynamically set ansible_python_interpreter at some point in my site playbook and have it trickle down to all of the playbooks I’m including, the roles that they’re using, etc. But when I set variables in site, they don’t seem to be available in the sub-playbooks I include there.

Where’s the best place to do this? Would I be better off making a separate “bootstrap” playbook and using a shell script to invoke the bootstrap playbook, then the real playbook sequentially? Would I be able to set these variables on the command-line then and have them work?

Thanks.

2

The ansible_python_interpreter variable needs to be set in your inventory. This page in the manual will give you the details on how it should be setup:

http://www.ansibleworks.com/docs/patterns.html#list-of-reserved-inventory-parameters

3

I've set it in group_vars before and had it work.

However, the problem is that I don't know until runtime what the full path
is going to be, since the interpreter is stored in the home directory of
the user executing Ansible. I _might_ be able to effect some changes in our
systems so that that's the case.

4

Here’s a neat idea.

You could consider setting gather_facts: False in the playbook, and write a facts module in a language other than python (bash is fine, just return key=value pairs and Ansible doesn’t even need JSON), that you explicitly call as the first step of your playbook, that returns an ansible_python_interpreter fact.

  • hosts: all
    gather_facts: False
    tasks:
  • action: site_facts

now run the regular facts module since we are good to go

  • action: setup

  • regular tasks go here

5

Thanks, that might just work. Just to save myself a little experimentation,
to set facts using a k/v style response, do I need to set a single key
called ansible_facts and then... stuff beneath it? Or does every key become
a fact?

Regardless, I can make it work. You've gotten me over two conceptual
barriers, namely, first, that I could run ANY module other than "raw" or
"shell" without a sane Python environment, and second, that I could set
facts from that. Yesterday I was attempting to use "register" with a shell
execution, which wasn't going so well.