Open Stack

On Wed, 2016-02-24 at 11:40 -0500, Sean Dague wrote:
> On 02/24/2016 11:28 AM, James Bottomley wrote:
> > 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). 
> 
> Um... since when are URLs generically case insensitive? The host
> portion
> is - https://tools.ietf.org/html/r
> https://tools.ietf.org/html/rfc3986#section-3.2.2c3986#section-3.2.2 
> and the scheme
> portion is - https://tools.ietf.org/html/rfc3986#section-3.1 however
> nothing about the PATH specifies that it should or must be (in
> section 3.3)

Heh, OK, I'm out of date.  When we first argued over this, Microsoft
required case insensitive matching for the path component because IIS
was doing lookups on vfat filesystems which are naturally case
insensitive.  If that's been excised from the standard, I'm happy to
keep it in the dustbin of history.

> While it's a little off topic, this is the 2nd time in a month it 
> came up, so I'd like to know if there is a reference for the case
> insensitive pov.

I checked; it looks to be implementation specific.  So php, for
instance, does case sensitive

/index.php != /Index.php

But drupal does case insensitive

/node/6 == /Node/6 == /NoDe/6

So all in all, a bit of a mess.

James