Thanks mriedem for answering my previous question, and also pointing out the related previous spec around just forcing all metadata to be lowercase:
(Spec: approved in Newton) https://review.openstack.org/#/c/311529/ (Online migration: not merged, abandoned) https://review.openstack.org/#/c/329737/ There are other code patches, but the above is representative. What I had read was the original bug: https://bugs.launchpad.net/nova/+bug/1538011 The tl;dr is that the default collation used by MySQL results in a bug when creating 2 metadata keys which differ only in case. The proposal was obviously to simply make all metadata keys lower case. However, as melwitt pointed out in the bug at the time that's a potentially user hostile change. After some lost IRC discussion it seems that folks believed at the time that to fix this properly would seriously compromise the performance of these queries. The agreed way forward was to allow existing keys to keep their case, but force new keys to be lower case (so I wonder how the above online migration came about?). Anyway, as Rajesh's patch shows, it's actually very easy just to fix the MySQL misconfiguration: https://review.openstack.org/#/c/504885/ So my question is, given that the previous series remains potentially user hostile, the fix isn't as complex as previously believed, and it doesn't involve a performance penalty, are there any other reasons why we might want to resurrect it rather than just go with Rajesh's patch? Or should we ask Rajesh to expand his patch into a series covering other metadata? Matt -- Matthew Booth Red Hat OpenStack Engineer, Compute DFG Phone: +442070094448 (UK) __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
