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 __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev