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 _______________________________________________ OpenStack-operators mailing list OpenStack-operators@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
