[openstack-dev] [glance][nova] images v1-v2 property name asymmetry
flavio at redhat.com
Thu Feb 25 18:29:10 UTC 2016
On Thu, Feb 25, 2016 at 2:53 AM, Brian Rosmaita <
brian.rosmaita at rackspace.com> wrote:
> 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
NIT: I think you meant v1 here
> - 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 .
> 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  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
> 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  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.
I think I'd let the image API enforce this, as you've suggested.
We could even keep the API as is and just make case-insensitve queries to
avoid duplicates. Do we care about the original case at all?
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the OpenStack-dev