Ansible vars_prompt in separate file

Question

Standard variables can be located in separate files by hosts and/or groups. Eg. group_vars/groupname or host_vars/hostname.

Is it possible to set vars_prompt in any other location than in playbook file? For example ideally directly in group_vars/groupname or group_vars_prompt/groupname?

Didn't find any relevant documentation. Thanks

Answer 1

Afaik, you can not do that. At best, you could use a dynamic inventory script that calls read like so:

#!/bin/bash
read foo                                                                               
cat <<EOF
{
  "localhost": {
     "hosts": [ "localhost" ]
   },
   "_meta" : {
    "hostvars" : {
      "localhost": {
        "foo": "$foo"
      }
    }
  }
}
EOF

But since ansible swallows STDOUT and STDERR when executing an inventory script (see: https://github.com/ansible/ansible/blob/devel/lib/ansible/inventory/script.py#L42), you won't be able to show a question prompt whatever file descriptor you write to.

As an alternative, if you're running under X, you could use Zenity:

#!/bin/bash
foo=`zenity  --title "Select Host" --entry --text "Enter value for foo"`

cat <<EOF
{
  "localhost": {
     "hosts": [ "localhost" ]
   },
   "_meta" : {
    "hostvars" : {
      "localhost": {
        "foo": "$foo"
      }
    }
  }
}
EOF

This way, you'll get a (GUI) prompt.

But I don't think this is desirable anyway, since it can fail in hundred ways. May be you could try an alternate approach, or tell us what you're trying to achieve.

Alternate approaches

• use vars files, filled by users or a script
• use ansible -e command line options, eventually wrapped in a bash script reading vars, eventually with zenity if you need UI
• let users fill inventory files (group_vars/whatever can be a directory, containing multiple files)
• use lookup with pipe to read from a script
• use lookup with env, to read vars from environment variables
• use Ansible Tower with forms
• use vars_prompt (falling back to defaults if nothing is entered), because the playbook is probably the best place to do this
• ...

Any of these solutions is probably better that hacking around inventory which should really be available unattended (because you might run later from Tower, because you might execute from cron, because you might ansible-pull, ...).