Open Stack

Here's the situation:

image property set:
- Images v1 API: all image property names are converted to lowercase
before they're stored
- Compute v2 API: all image property names are converted to lowercase
before they're stored
- Images v2 API: image properties are stored in the case specified when
they were created

image property get:
- Images v2 API: all image property names are returned in lowercase only
- Compute v2 API: all image property names are returned in lowercase only
- Images v2 API: image property names are returned as originally set

Note: this applies only to property NAMES.  In all 3 APIs, values are
returned in the same case pattern in which they were created.  Details of
the above are avaliable on an etherpad [2].

Here is why this matters.
(1)  Current Glance behavior is that property names are treated as if they
were un-cased.  In other words, if you create a property
'CamelCasedPropertyName' on image 1234, you cannot create another property
named 'camelCasedPropertyName' on image 1234.  Adding "duplicate"
properties in v2 is currently blocked more by a fortuitous bug than by
design.  If this is the behavior we want (and I think it is), then we need
to make the duplication detection more robust.

(2)  The current patch for the CIM metadata definitions [0] is defining
property names in all lowercase, for example,
'instructionsetextensionname' instead of 'InstructionSetExtensionName' as
on an earlier patch.  In addition to being more readable, the CamelCased
names are what's actually used in the CIM schema.  Lin's reason for the
change is that if image consumers looking for image metadata are using the
Images v1 or the Compute API, they won't find CamelCased property names
among the image properties.  By keeping everything lowercase, we eliminate
the problem of a developer forgetting to normalize image property names
before testing for their existence.

(3)  This issue impacts the work underway to convert Nova to consuming the
Images v2 API.

We need to formalize the intended behavior.  Here's a proposal:
(a) If you use the Images v1 API or the Compute API to *set* an image
property name, you get lowercase only.
(b) If you use the Images v1 API or the Compute API to *get* an image
proeprty name, you get lowercase only.
(c) The behavior of the Compute API with respect to image property names
should not change when Nova starts using the Images v2 API.
(d) If you use the Images v2 API to *set* image property names, they are
stored as cased in the request.
(e) For the purposes of preventing duplicate image property names on a
single image, property names are *case insensitive*.
(f) If you use the Images v2 API to *get* image property names, you will
receive them as they were stored, but you should treat them as case
insensitive.

This proposal is basically what we've got now, plus the recommendation
that image property names be treated as case insensitive when using the
Images v2 API.

We need to get consensus on this quickly so that the implementation of the
CIM Namespace Metadata spec [1] can be completed.  The hold up at the
moment is whether the property names should be CamelCased or simply
lowercased.  My opinion is that if everyone's going to make all property
names lowercase just to be safe, then we ought to go ahead and enforce
this in the Images API, that is, make the Images v2 API act just like the
Images v1 API in this regard.

cheers,
brian


[0] https://review.openstack.org/#/c/265152/6
[1] 
http://specs.openstack.org/openstack/glance-specs/specs/mitaka/approved/cim
-namespace-metadata-definitions.html
[2] https://etherpad.openstack.org/p/images-v1-v2-property-names-asymmetry