Open Stack

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 [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.
>

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?

Flavio

-- 
@flaper87
Flavio Percoco
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20160225/18538d48/attachment.html>