Comment 4 for bug 1492748

OK, I am seeing this exact behavior on trusty-kilo.

The problem seems to be that because of the fix made for LP 1493931, the hostname
set on cinder.conf for the cinder Service is the service_name(), which on this case is cinder or cinder-ceph.

You can see this definition here: https://github.com/openstack/cinder/blob/c1870433ae72cbfacbf0909921ca18401f84653d/cinder/service.py#L243

My understanding is that this is required for HA deployments using a stateless
backend, in order to keep performing operations on the volumes, regardless of the
service location.

This is my current setup, the service is never updated since deployed,
because the report_state method is using the newly created service instance (which points to the host cinder).

mysql> select updated_at, host, report_count, topic from services;
+---------------------+-------------------------------+--------------+------------------+
| updated_at | host | report_count | topic |
+---------------------+-------------------------------+--------------+------------------+
| 2016-02-04 16:43:50 | juju-niedbalski-sec-machine-6 | 5 | cinder-scheduler |
| 2016-02-04 16:43:54 | juju-niedbalski-sec-machine-5 | 3 | cinder-scheduler |
| 2016-02-04 16:43:30 | juju-niedbalski-sec-machine-6 | 9 | cinder-volume |
| 2016-02-04 16:43:13 | juju-niedbalski-sec-machine-7 | 7 | cinder-volume |
| 2016-02-04 16:43:13 | juju-niedbalski-sec-machine-7 | 1 | cinder-scheduler |
| 2016-02-04 16:43:34 | juju-niedbalski-sec-machine-5 | 7 | cinder-volume |
| 2016-02-04 17:31:11 | cinder@cinder-ceph | 845 | cinder-volume |
| 2016-02-04 17:31:10 | cinder | 834 | cinder-scheduler |
+---------------------+-------------------------------+--------------+------------------+
8 rows in set (0.00 sec)

mysql>

However I am not entirely sure if this is approach is completely correct since after
creating a volume I can't see the reference to the host.

mysql> select host, id, size, provider_location from volumes;
+------+--------------------------------------+------+-------------------+
| host | id | size | provider_location |
+------+--------------------------------------+------+-------------------+
| NULL | fb7870b5-f0cf-4913-ac98-697c65351c15 | 10 | NULL |
+------+--------------------------------------+------+-------------------+
1 row in set (0.00 sec)

So, what's the correct fix for this? Delete the older entries on the DB after deployment?

Any suggestion?