[Openstack-operators] Cinder Juno to Kilo upgrade and DB encodings
Mathieu Gagné
mgagne at internap.com
Thu Sep 17 16:11:23 UTC 2015
On 2015-09-17 4:06 AM, Arne Wiebalck wrote:
> Hi,
>
> During our Cinder upgrade on CentOS7 from Juno to Kilo, we ran into this bug:
> https://bugs.launchpad.net/cinder/+bug/1455726
>
> As there is no fix available from what I see, what we came up with as a “solution”
> is to explicitly set the character and the collation in all existing tables in the database
> before the upgrade:
>
> —>
> alter database cinder CHARACTER SET utf8 COLLATE utf8_unicode_ci;
> SET foreign_key_checks = 0;
> ALTER TABLE `backups` CONVERT TO CHARACTER SET utf8 COLLATE utf8_unicode_ci;
> ALTER TABLE `cgsnapshots` CONVERT TO CHARACTER SET utf8 COLLATE utf8_unicode_ci;
> ALTER TABLE `consistencygroups` CONVERT TO CHARACTER SET utf8 COLLATE utf8_unicode_ci;
> ALTER TABLE `encryption` CONVERT TO CHARACTER SET utf8 COLLATE utf8_unicode_ci;
> ALTER TABLE `iscsi_targets` CONVERT TO CHARACTER SET utf8 COLLATE utf8_unicode_ci;
> ALTER TABLE `migrate_version` CONVERT TO CHARACTER SET utf8 COLLATE utf8_unicode_ci;
> ALTER TABLE `quality_of_service_specs` CONVERT TO CHARACTER SET utf8 COLLATE utf8_unicode_ci;
> ALTER TABLE `quota_classes` CONVERT TO CHARACTER SET utf8 COLLATE utf8_unicode_ci;
> ALTER TABLE `quota_usages` CONVERT TO CHARACTER SET utf8 COLLATE utf8_unicode_ci;
> ALTER TABLE `quotas` CONVERT TO CHARACTER SET utf8 COLLATE utf8_unicode_ci;
> ALTER TABLE `reservations` CONVERT TO CHARACTER SET utf8 COLLATE utf8_unicode_ci;
> ALTER TABLE `services` CONVERT TO CHARACTER SET utf8 COLLATE utf8_unicode_ci;
> ALTER TABLE `snapshot_metadata` CONVERT TO CHARACTER SET utf8 COLLATE utf8_unicode_ci;
> ALTER TABLE `snapshots` CONVERT TO CHARACTER SET utf8 COLLATE utf8_unicode_ci;
> ALTER TABLE `transfers` CONVERT TO CHARACTER SET utf8 COLLATE utf8_unicode_ci;
> ALTER TABLE `volume_admin_metadata` CONVERT TO CHARACTER SET utf8 COLLATE utf8_unicode_ci;
> ALTER TABLE `volume_glance_metadata` CONVERT TO CHARACTER SET utf8 COLLATE utf8_unicode_ci;
> ALTER TABLE `volume_metadata` CONVERT TO CHARACTER SET utf8 COLLATE utf8_unicode_ci;
> ALTER TABLE `volume_type_extra_specs` CONVERT TO CHARACTER SET utf8 COLLATE utf8_unicode_ci;
> ALTER TABLE `volume_types` CONVERT TO CHARACTER SET utf8 COLLATE utf8_unicode_ci;
> ALTER TABLE `volumes` CONVERT TO CHARACTER SET utf8 COLLATE utf8_unicode_ci;
> SET foreign_key_checks = 1;
> <—
>
> Note that in our case the databases default character set was already utf8 everywhere, while the collation
> was utf8_general_ci. With that conversion the upgrade seems to work fine in our tests.
>
> Before we retry the upgrade: do if people here think that this a reasonable approach or will this cause
> other issues? Are there alternative approaches?
>
In our case, we ran this command before upgrading:
ALTER DATABASE cinder CHARACTER SET utf8 COLLATE utf8_general_ci;
See this thread about the same problem:
http://lists.openstack.org/pipermail/openstack/2015-August/013599.html
And the proposed solution:
http://lists.openstack.org/pipermail/openstack/2015-August/013601.html
I suspect that people using Puppet to deploy OpenStack are encountering
this issue due to this change:
https://review.openstack.org/#/c/175991/
We thought this change wouldn't affect anyone but it looks it does.
--
Mathieu
More information about the OpenStack-operators
mailing list