MySQL backend: Updating flavor extra-specs with altered case throws conflicts

[Nicolas Simonds]

The DB query for flavor extra-specs is case-insensitive, but the code to handle update vs. create is case-sensitive. This causes unexpected behavior when trying to "fix" case on extra-specs:

Steps to reproduce:

    Stand up a devstack with the MySQL backend.

    nova flavor-key set 1 aaa=haha
    nova flavor-key set 1 AAA=lolz

Expected results:

Option 1: Two extra specs, named "aaa" and "AAA", with distinct values

Option 2: The extra spec named "aaa" replaced with "AAA"

Actual results:

a 409 Error from the client, and an exception throwing the exception on the backend

[OpenStack Infra (hudson-openstack)]

Fix proposed to branch: master
Review: https://review.openstack.org/190300

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.openstack.org/190300
Committed: https://git.openstack.org/cgit/openstack/nova/commit/?id=402b3abf990d08d2af8331079d36a92d84d84b80
Submitter: Jenkins
Branch: master

commit 402b3abf990d08d2af8331079d36a92d84d84b80
Author: Nicolas Simonds <email address hidden>
Date: Wed Jun 10 11:59:11 2015 -0700

    Use utf8_bin collation on the flavor extra-specs table in MySQL

    On the MySQL backend, change the collation type on flavor extra-specs
    to be utf8_bin, i.e., case-sensitive.

    Other backends (e.g., SQLite) are case-sensitive, and the code
    around extra-spec duplicate detection assumes this is universally
    true. This author is of the opinion that treating what is essentially
    user-input as case-sensitive is a good idea, so assume the code is
    correct, and fix the database.

    TrivialFix
    Change-Id: I64f1cc1b5c604085f879a25cbbd47c04b05e096d
    Closes-Bug: 1463948