ansible_python_interpreter, variable scope, and bootstrapping

[Andrew Todd]

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.

[James Cammarata]

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

 

--

James Cammarata <jcamm...@ansibleworks.com>
Sr. Software Engineer, AnsibleWorks, Inc.
http://www.ansibleworks.com/

[Andrew Todd]

On Mon, Aug 5, 2013 at 8:23 PM, James Cammarata <jcamm...@ansibleworks.com> wrote:

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

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.

[Michael DeHaan]

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

--
You received this message because you are subscribed to the Google Groups "Ansible Project" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ansible-proje...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

--

Michael DeHaan <mic...@ansibleworks.com>
CTO, AnsibleWorks, Inc.
http://www.ansibleworks.com/

[Andrew Todd]

On Tue, Aug 6, 2013 at 10:07 AM, Michael DeHaan <mic...@ansibleworks.com> wrote:

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.

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.