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

James Bottomley James.Bottomley at HansenPartnership.com
Wed Feb 24 16:28:50 UTC 2016


On Wed, 2016-02-24 at 07:48 -0500, 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.

This is actually one of the curses wished on us by REST.  Since the
intent is to use web requests for the API, the API name must follow the
case sensitivity rules for URL matching (case insensitive).  However,
the rest of the parameters can be case sensitive.  That means that if
your column name maps to an API, it must be case insensitive, but if it
maps to a data input it may be case sensitive.

I think option 1 is the best course, but someone will have to take a
look and make sure there are no APIs that suddenly have case
insensitivity rules for data inputs that aren't expressed currently.

James





More information about the OpenStack-dev mailing list