1435a15ce3
In trying to figure out why I was unable to run all of the test_migrations tests, I realized we need to fix and clean up our unicode declarations. Specifically, the way I found this was my local mysql install was defaulted to using 4 Byte Unicode characters, however some of our fields are 255 characters, which do not fit inside of InnoDB tables. They do, however fit with the "utf8" storage alias, which is presently short for UTF8MB3, as opposed to UTF8MB4 which is what my local database server was configured for. Because this was in opportunistic tests, I wasn't able to really sort out what was going on and thought we needed to shorten the fields. In reality, it turns out we never defined the allocations table to use UTF8 and Innodb for storage. Storage engine wise, this is not a big deal, but may mean a DBA will one day need to dump and reload the allocation table of a deployment. Character set wise... It is not great, but there is not a good way for us to do this programatically. In my opinion, the chance of an issue being encountered by an operator is unlikely, which out weighs the risk and impact of dumping the entire table, deleting the table, recreating the table with the updated schema and then repopulating the entries. Of course, if operators are not using allocations, then it really doesn't matter for them. Along the way, I discovered we had used the "UTF8" type alias, which may change one day, which would break Ironic. As such, I've also updated the definitions used to create databases and updated our documentation. Recommended reading: https://docs.sqlalchemy.org/en/14/dialects/mysql.html#unicode https://dev.mysql.com/doc/refman/8.0/en/charset-unicode-utf8mb4.html Story: 2010348 Task: 46492 Change-Id: I4103152489bf61e2d614eaa297da858f7b2112a3
24 lines
1.3 KiB
YAML
24 lines
1.3 KiB
YAML
---
|
|
fixes:
|
|
- |
|
|
Fixes an missing MySQL/MariaDB character set configuration and default
|
|
table type encoding for the ``allocations`` database table. Previously,
|
|
If Ironic's database was attempted to be populated on a machine which
|
|
was using 4 byte character encoding, such as MySQL/MariaDB on Debian
|
|
based systems, then the database schema creation would fail.
|
|
upgrade:
|
|
- This upgrade updates the default character set to utilized in the
|
|
database tables when using MySQL/MariaDB. Previously, the default
|
|
for Ironic was ``UTF8``, however we now explicitly set ``UTF8MB3``
|
|
which is short for "3 byte UTF8" encoding. The exception to this
|
|
is the ``allocations`` table, which would just rely upon the database
|
|
default. This was done as Ironic's database schema is incompatible
|
|
with MySQL/MariaDB's ``UTF8MB4``, or "4 byte UTF8" character encoding
|
|
and storage constraints.
|
|
- Upgrading will change the default chracter encoding of all tables.
|
|
For most tables, this should be an effective noop, but may result in
|
|
transitory table locks. For the ``allocations`` table, it will need to
|
|
be re-written, during which the database engine will have locked the
|
|
table from being used. Operators are advised to perform test upgrades
|
|
and set expectation and upgrade plans accordingly.
|