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

Bug #1305582 reported by Pierre Amadio
60
This bug affects 12 people
Affects Status Importance Assigned to Milestone
mysql (Juju Charms Collection)
Confirmed
Undecided
Unassigned

Bug Description

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

Tags: openstack cts
Revision history for this message
Louis Bouchard (louis) wrote :
Download full text (4.2 KiB)

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...

Read more...

affects: glance (Juju Charms Collection) → mysql (Juju Charms Collection)
Changed in mysql (Juju Charms Collection):
status: New → Confirmed
Revision history for this message
Louis Bouchard (louis) wrote :

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

Revision history for this message
QuentinHartman (qhartman) wrote :

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.

tags: added: openstack
tags: added: cts
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.