Module provided facts. but using shell script

Archives Ansible Project
1

Dear List,

I’d like to run a “site_facts” shell program on the intended host to pick up some variables that are defined on the host’s filesystem.
I read this: “http://ansible.cc/docs/moduledev.html#module-provided-facts” and understand how it should be done using python and the json import thing.

Could it be done using a shell program though? I’d like to read a file on the host, and return the contents back ansible for use in later actions (Especially with the template module)

Is there a special invocation I need to use with my shell module so I can return facts for later use?

Thanks,
Mark

2

You can easily do it in shell or any programming language as long as
you return JSON format.

Be careful with your prints and your shell module can echo back JSON just fine.

--Michael

3

You can easily do it in shell or any programming language as long as
you return JSON format.

Be careful with your prints and your shell module can echo back JSON just fine.

Ok, but I’m not getting the variables inside the template:

Extremely simplified, just to understand what I’m getting:

1.) The shell module I’m sending:

mmaas@XXXXXX:~/playbooks$ cat ./XXXXXX/library/omgeving
#!/bin/bash
cat /etc/ansible/local_vars

2.) The contents of /etc/ansible/local_vars on the host:

mmaas@xmonopsview:/etc/ansible$ cat ./local_vars

{

“host”: “XXXXXX”,

“port”: “50000”

}

3.) The playbook:

mmaas@XXXXXX:~/playbooks$ cat ./XXXXXX/local_vars_test.yml

  • hosts: XXXXXX

vars:

email: unixbeheer@XXXXXX.nl

smarthost: pex1.cname.XXXXXX.nl

user: mmaas

sudo: true

tasks:

  • name: Local vars ophalen

action: omgeving

  • name: Template neerzetten

action: template src=…/templates/local_vars_test.j2 dest=/etc/ansible/templated.conf owner=root group=root mode=0644

4.) And the result when running:

mmaas@XXXXXX:~/playbooks$ ansible-playbook -K ./XXXXXX/local_vars_test.yml -v

sudo password:

PLAY [XXXXXX] *********************

GATHERING FACTS *********************

ok: [XXXXXX]

TASK: [Local vars ophalen] *********************

ok: [XXXXXX] => {“host”: “XXXXXX”, “port”: “50000”}

TASK: [Template neerzetten] *********************

ok: [XXXXXX] => {“changed”: false, “dest”: “/etc/ansible/templated.conf”, “group”: “root”, “md5sum”: “68b329da9893e34099c7d8ad5cb9c940”, “mode”: “0644”, “owner”: “root”, “src”: “/home/mmaas/.ansible/tmp/ansible-1352902982.54-257885461491988/source”, “state”: “file”}

PLAY RECAP *********************

XXXXXX: ok=3 changed=0 unreachable=0 failed=0

But the “/etc/ansible/templated.conf” on the intended host is empty after this run.

4.) The template file is also very simple for now:

mmaas@XXXXXX:~/playbooks$ cat ./templates/local_vars_test.j2

{{ host }}

{{ port }}

Thanks again,
Mark

4

Yeah, in order to create facts, it needs something like this:

{
    "ansible_facts" : {
        "foo" : "some string",
        "baz" : 1234
    }
}

This will make $foo and $bar available.

Leaving out the "ansible_facts" hash and surfacing foo/bar at the top
level won't do anything.

This is how Ansible tells something is setting facts or not. Any
module, even one that causes other side effects, can set variables in
this way by including the "ansible_facts" hash/dictionary.

Hope this helps!

--Michael

5

Excellent!

So that was the trick. Anyway to do this same thing but with the shorthand version?
http://ansible.cc/docs/moduledev.html#shorthand-vs-json

Thanks,
Mark

6

I think we need to remove the docs on the shorthand version because it
doesn't work (i.e. not supported) anymore, but need to confirm.

It probably would be better to make it work again, if so, instead :slight_smile:

What I'm suggesting is you print out a valid JSON string, actually.

You can do it over multiple lines if it makes it easier for the bash script.

7

I have used the shorthand version just fine, trying to write a module
in bash. I might not gte the business logic right, but getting the
values back to ansible works fine. Twiddling "facts" might be
something else, but I'd hate to see the shorthand system go away now
when I've started using it.

/andreas

8

Yeah, we confirmed the shorthand version works fine as of last night,
so I was incorrect in thinking I had broken it. I believe we even
have a test :slight_smile: