© 2004
Canonical Ltd.
•
Terms of use
•
Data privacy
•
Contact Launchpad Support
•
Blog
•
Careers
•
System status
•
1b1ed1a
(Get the code!)
Hi Doug Hellmann,
Sorry for the delay response.
>>>> IIUC, we need all of the tables to have the same character set in order
for foreign key constraints to work properly
(https:/
above would provide a switch to turn off character set checking, which
would allow tables to not have the same character set. Is that wise?
What effect would that have on future migrations?
Actually I think we are on the same page on this point. The purpose for the
switch is just for provide a temporary disablement on the checking to give deployer a chance to
execute automatic utf8 table charset migration script, otherwise all the migrations will be blocked. So after that, the final charset of the tables will all under unified utf8. So this will not effect future migrations as well.
>>>> It also appears that enabling the switch requires a change in the
migration driving program for each project (glance-manage, etc.). Is
there a way to define that option centrally so that all projects have
it?
Yes, it's a worth way to go, but TBH IMHO seems there is not a common way. Like to know other folks input.
>>>> Why is glance the only project reporting this issue? Have we just not
hit it in other projects?
I think other projects should have this similar issue after they synced that utf8 check code from oslo-db.
>>>> It looks like nova resolved the issue by
providing an alter script that ensures the character sets for all the
tables are utf8
(https:/
Does glance need a similar change? I realize those sorts of changes can
be rather expensive, so we would want to isolate the migration as a
single step in the migration process and make sure it is highlighted in
the release notes so deployers are aware of it.
Yep, agreed. Actually I prepared a migration for Glance, and after my oslo change get mreger I will push it landing:
https:/