[openstack-dev] [nova] solving API case sensitivity issues

Michał Dulko michal.dulko at intel.com
Thu Feb 25 16:35:21 UTC 2016

On 02/24/2016 01:48 PM, Sean Dague wrote:
> We have a specific bug around aggregrate metadata setting in Nova which
> exposes a larger issue with our mysql schema.
> https://bugs.launchpad.net/nova/+bug/1538011
> On mysql the following will explode with a 500:
>> nova aggregate-create agg1
>> nova aggregate-set-metadata agg1 abc=1
>> nova aggregate-set-metadata agg1 ABC=2
> mysql (by default) treats abc == ABC. However the python code does not.
> We have a couple of options:
> 1) make the API explicitly case fold
> 2) update the mysql DB to use latin_bin collation for these columns
> 3) make this a 400 error because duplicates were found
> Options 1 & 2 make all OpenStack environments consistent regardless of
> backend.
> Option 2 is potentially expensive TABLE alter.
> Option 3 gets rid of the 500 error, however at the risk that the
> behavior for this API is different depending on DB backend. Which is
> less than ideal.
> My preference is slightly towards #1. It's taken a long time for someone
> to report this issue, so I think it's an edge case, and people weren't
> think about this being case sensitive. It has the risk of impacting
> someone on an odd db platform that has been using that feature.
> There are going to be a few other APIs to clean up in a similar way. I
> don't think this comes in under a microversion because of how deep in
> the db api layer this is, and it's just not viable to keep both paths.
> 	-Sean

We've faced similar issues in Cinder and as solution we've moved
filtering to Python code. Like in for example [1] or [2]. But no, we
haven't had UNIQUE constraint on the DB column in these cases, only on IDs.

[1] https://review.openstack.org/225024
[2] https://review.openstack.org/#/c/274589/12/cinder/db/sqlalchemy/api.py

More information about the OpenStack-dev mailing list