Comment 8 for bug 1279000

I'm having some trouble understanding how the proposed change fits into the bigger picture.

IIUC, we need all of the tables to have the same character set in order for foreign key constraints to work properly (https://bugs.launchpad.net/heat/+bug/1261605). The change proposed 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?

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?

Why is glance the only project reporting this issue? Have we just not hit it in other projects? It looks like nova resolved the issue by providing an alter script that ensures the character sets for all the tables are utf8 (https://github.com/openstack/nova/blob/0a2ab98491cbf62e148e8289bc69c26357bd136c/nova/db/sqlalchemy/migrate_repo/versions/170_havana.py#L1395). 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.