Nova flavor extra_spec is case sensitive

[Tan Lin]

flavor extra_spec is case sensitive, we should make it insensitive which is more robust and improve user experience, like `Trusted` should be accepted as well as `trusted`

[Markus Zoeller (markus_z) (mzoeller)]

Confirmed: The "trusted_filter" for example uses a case sensitive comparison [1]:

    def is_trusted(self, host, trust):
        level = self.caches.get_host_attestation(host)
        return trust == level

[1] https://github.com/openstack/nova/blob/master/nova/scheduler/filters/trusted_filter.py#L249

[Markus Zoeller (markus_z) (mzoeller)]

In Progress: Tan Lin is set as assignee.

[Rui Chen (kiwik-chenrui)]

Adds patch link:

https://review.openstack.org/#/c/193047/

[OpenStack Infra (hudson-openstack)]

Change abandoned by Michael Still (<email address hidden>) on branch: master
Review: https://review.openstack.org/193047
Reason: This patch has been stalled for quite a while, so I am going to abandon it to keep the code review queue sane. Please restore the change when it is ready for review.

[Dave Johnston (dave-johnston)]

Should this be progressed? Can we get agreement on whether filters should be case sensitive or not?

I've seen particular situation where different users are responsible for creating flavors and extra_specs on a host aggregate. In that situation case sensitivity can be more of a pain.

i.e.
User one creates flavors to support CPU pinning

nova flavor-key compute-optimized.small set aggregate_instance_extra_specs:pinned"="false";

User two who racks the hardware and configures it in Openstack, specifies which machines can be used for dedicated CPU pinning

nova aggregate-set-metadata 2 pinned=False

In this scenario the operators would want false == False.

Are there any scenarios where case insensitivity would be undesirable?