relation with mysql fail when mysql and glance are deployed on the same node

[Pierre Amadio]

I m deploying havanna in a sandbox.
Full deployment guide is available here:
http://bazaar.launchpad.net/~pierre-amadio/+junk/c6100-server-12.04-juju-core-havana/files

README.txt describe all the installation process
openstack.yaml is the juju openstack.yaml file used to deploy things.

There s a controller node where several charms are located, among them, mysql and glance:

controller.mydomain.com 192.168.101.10

When setting a relation between mysql and glance, glance ends up with an error:

agent-state-info: 'hook failed: "shared-db-relation-changed"'

In juju debug-logs:

unit-glance-0: 2014-04-10 08:07:01 INFO shared-db-relation-changed 2014-04-10 08:07:01.352 1879 TRACE glance OperationalError: (OperationalError) (1130, "Host '192.168.101.10' is not allowed to connect to this MySQL server") None None

If i log as root in the mysql db, i see there s only 1 entry for the glance user, and it is not associated with the ip of the controller node, but only with the loopback address.

mysql> select Host,User,Password from user where User='glance';
+-----------+--------+-------------------------------------------+
| Host | User | Password |
+-----------+--------+-------------------------------------------+
| 127.0.0.1 | glance | *0107778671E896327E8B418F26E909C5E398E725 |
+-----------+--------+-------------------------------------------+
1 row in set (0.00 sec)

The controller nodes resolve controller.mydomain.com as 127.0.0.1 because of the following entry in /etc/hosts:

# Added by cloud-init on Wed, 09 Apr 2014 14:37:59 +0000
127.0.1.1 controller.mydomain.com controller

It looks to me the entry in the mysql database for the glance user should not have been the loopback address but 192.168.101.10

ubuntu@maas:~$ cat charms/precise/mysql/revision
311
ubuntu@maas:~$ cat charms/precise/glance/revision
148

[Louis Bouchard (louis)]

I see the same behavior when setting up a relation between mysql & keystone.

If I run mysql & keystone on two separate machines, the add-relation works fine.

 If done on the same machine, it fails with the following :

unit-keystone-0: 2014-04-10 09:47:57 ERROR juju.worker.uniter uniter.go:475 hook failed: exit status 1
unit-keystone-0: 2014-04-10 09:55:07 INFO juju-log shared-db:6: db_host or password not set. Peer not ready, exit 0
unit-keystone-0: 2014-04-10 09:55:16 INFO juju-log shared-db:6: Cluster leader, performing db-sync
unit-keystone-0: 2014-04-10 09:55:17 INFO shared-db-relation-changed 2014-04-10 11:55:17.096 10512 CRITICAL keystone [-] (OperationalError) (1
130, "Host '192.168.122.154' is not allowed to connect to this MySQL server") None None
unit-keystone-0: 2014-04-10 09:55:22 INFO shared-db-relation-changed Traceback (most recent call last):
unit-keystone-0: 2014-04-10 09:55:22 INFO shared-db-relation-changed File "/var/lib/juju/agents/unit-keystone-0/charm/hooks/shared-db-relati
on-changed", line 570, in <module>
unit-keystone-0: 2014-04-10 09:55:22 INFO shared-db-relation-changed utils.do_hooks(hooks)
unit-keystone-0: 2014-04-10 09:55:22 INFO shared-db-relation-changed File "/var/lib/juju/agents/unit-keystone-0/charm/hooks/lib/utils.py", l
ine 28, in do_hooks
unit-keystone-0: 2014-04-10 09:55:22 INFO shared-db-relation-changed hook_func()
unit-keystone-0: 2014-04-10 09:55:22 INFO shared-db-relation-changed File "/var/lib/juju/agents/unit-keystone-0/charm/hooks/shared-db-relati
on-changed", line 180, in db_changed
unit-keystone-0: 2014-04-10 09:55:22 INFO shared-db-relation-changed ensure_initial_admin(config)
unit-keystone-0: 2014-04-10 09:55:22 INFO shared-db-relation-changed File "/var/lib/juju/agents/unit-keystone-0/charm/hooks/keystone_utils.p
y", line 337, in ensure_initial_admin
unit-keystone-0: 2014-04-10 09:55:22 INFO shared-db-relation-changed create_tenant("admin")
unit-keystone-0: 2014-04-10 09:55:22 INFO shared-db-relation-changed File "/var/lib/juju/agents/unit-keystone-0/charm/hooks/keystone_utils.p
y", line 231, in create_tenant
unit-keystone-0: 2014-04-10 09:55:22 INFO shared-db-relation-changed tenants = [t._info for t in manager.api.tenants.list()]
unit-keystone-0: 2014-04-10 09:55:22 INFO shared-db-relation-changed File "/usr/lib/python2.7/dist-packages/keystoneclient/v2_0/tenants.py",
 line 117, in list
unit-keystone-0: 2014-04-10 09:55:22 INFO shared-db-relation-changed tenant_list = self._list("/tenants%s" % query, "tenants")
unit-keystone-0: 2014-04-10 09:55:22 INFO shared-db-relation-changed File "/usr/lib/python2.7/dist-packages/keystoneclient/base.py", line 90
, in _list
unit-keystone-0: 2014-04-10 09:55:22 INFO shared-db-relation-changed resp, body = self.api.get(url)
unit-keystone-0: 2014-04-10 09:55:22 INFO shared-db-relation-changed File "/usr/lib/python2.7/dist-packages/keystoneclient/httpclient.py", l
ine 654, in get
unit-keystone-0: 2014-04-10 09:55:22 INFO shared-db-relation-changed return self._cs_request(url, 'GET', **kwargs)
unit-keystone-0: 2014-04-10 09:55:22 INFO shared-db-relation-changed File "/usr/lib/python2.7/dist-packages/keys...

[Louis Bouchard (louis)]

FYI, I'm seeing this on the local provider. Pierre sees it on a Maas deployment

[QuentinHartman (qhartman)]

I have the same behavior when working with MAAS and Juju, installing many openstack services collapsed onto a single node. I agree that the hosts entry ( in my case "127.0.1.1 qpx6p.maas qpx6p") is the root of the problem.

It seems that making this sort of entry would be problematic for a number of potential cloud deployment strategies. Wouldn't it be better to assume that there is functional DNS, and/or put a real IP in this hosts entry? It seems that would solve all the mysql-related problems that currently exist in the Trusty openstack-related charms.