problems with variables being passed to a role

Archives Ansible Project
1

Hi All

I’m getting an error like this…

TASK: [create user ‘{{opennebula_db_user}}’ with password ‘{{opennebula_db_pass}}’ for ‘{{opennebula_db}}’ and grant all priveleges] ***
failed: [192.168.206.110] => {“failed”: true, “item”: “”, “parsed”: false}
invalid output was: Traceback (most recent call last):
File “/root/.ansible/tmp/ansible-1372432356.33-79822485449444/mysql_user”, line 1304, in
main()
File “/root/.ansible/tmp/ansible-1372432356.33-79822485449444/mysql_user”, line 383, in main
changed = user_add(cursor, user, host, password, priv)
File “/root/.ansible/tmp/ansible-1372432356.33-79822485449444/mysql_user”, line 133, in user_add
cursor.execute(“CREATE USER %s@%s IDENTIFIED BY %s”, (user,host,password))
File “/usr/lib/python2.7/dist-packages/MySQLdb/cursors.py”, line 174, in execute
self.errorhandler(self, exc, value)
File “/usr/lib/python2.7/dist-packages/MySQLdb/connections.py”, line 36, in defaulterrorhandler
raise errorclass, errorvalue
_mysql_exceptions.OperationalError: (1470, “String ‘{{opennebula_db_user}}’ is too long for user name (should be no longer than 16)”)

FATAL: all hosts have already failed – aborting

PLAY RECAP ********************************************************************
to retry, use: --limit @/var/tmp/ansible/site-vagrant.retry

192.168.206.110 : ok=32 changed=27 unreachable=0 failed=1

The task is


# usernames and passwords should be included from a file outside of this git-repo, for now this is developmental.

- name: create user '{{opennebula_db_user}}' with password '{{opennebula_db_pass}}' for '{{opennebula_db}}' and grant all priveleges

  action: mysql_user state=present name={{opennebula_db_user}} password={{opennebula_db_pass}} priv={{opennebula_db}}.*:ALL

oddly it happens in a vagrant VM but it doesnt happen on my production system. The playbook can be found here... [https://github.com/jcftang/ansible-opennebula/blob/master/site-vagrant.yml](https://github.com/jcftang/ansible-opennebula/blob/master/site-vagrant.yml)

You can test it (assuming you have vagrant) by

  git clone [https://github.com/jcftang/ansible-opennebula.git](https://github.com/jcftang/ansible-opennebula.git)

  cd ansible-opennebula
  cd hacking
  vagrant up
  source env-setup

  cd ..
  ansible-playbook site-vagrant.yml

the production version of the playbook is site.yml which does the correct thing with variables being passwd to the mysql_user module. So I'm not sure why the jinja2 templates aren't being evaluation.

Any suggestions on debugging variables would be appreciated.

Jimmy,
2

So it’s a little unfair to ask us to use vagrant to duplicate and test your configuration, rather than boiling things down to a more basic example.

It looks like the only problem you have here is the variable isn’t being resolved.

It would help if you tell us where this is being defined but I suspect what is happening is in your vagrant setup your inventory file isn’t alongside your group_vars or something like that, so it’s not being loaded.

3

I’m defining the variable in “group_vars/all” the inventory file doesn’t have the relevent variable in there, but thats a good point about the inventory file not being next to the group_vars file. I wouldn’t have expected it to be a problem. I can try moving my inventory file next to the group_vars file and see how it goes…

4

Jimmy:

If you’re running off of the devel branch, I recommend you add the following line to your ansible.cfg file:

error_on_undefined_vars = True

This will give you a more meaningful error message if a variable isn’t defined.

Lorin

5

It was a problem with the inventory file not being next to the group_vars directory. I would have though it would have loaded up the group_vars directory of variables if it was sat next to my playbooks instead of my inventory file. Is by design that the inventory file must site next to the group_vars directory for everything to be evaluated correctly?

6

Ah neato, this is going into my installation wide ansible config.

7

Yeah, it’s supposed to work next to your top level playbooks, but I need to confirm that’s also operational.

(If playbooks are in different directories, it won’t be able to find them that way)