<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Feb 25, 2016 at 2:53 AM, Brian Rosmaita <span dir="ltr"><<a href="mailto:brian.rosmaita@rackspace.com" target="_blank">brian.rosmaita@rackspace.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Here's the situation:<br>
<br>
image property set:<br>
- Images v1 API: all image property names are converted to lowercase<br>
before they're stored<br>
- Compute v2 API: all image property names are converted to lowercase<br>
before they're stored<br>
- Images v2 API: image properties are stored in the case specified when<br>
they were created<br>
<br>
image property get:<br>
- Images v2 API: all image property names are returned in lowercase only<br></blockquote><div><br></div><div>NIT: I think you meant v1 here</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
- Compute v2 API: all image property names are returned in lowercase only<br>
- Images v2 API: image property names are returned as originally set<br>
<br>
Note: this applies only to property NAMES.  In all 3 APIs, values are<br>
returned in the same case pattern in which they were created.  Details of<br>
the above are avaliable on an etherpad [2].<br>
<br>
Here is why this matters.<br>
(1)  Current Glance behavior is that property names are treated as if they<br>
were un-cased.  In other words, if you create a property<br>
'CamelCasedPropertyName' on image 1234, you cannot create another property<br>
named 'camelCasedPropertyName' on image 1234.  Adding "duplicate"<br>
properties in v2 is currently blocked more by a fortuitous bug than by<br>
design.  If this is the behavior we want (and I think it is), then we need<br>
to make the duplication detection more robust.<br>
<br>
(2)  The current patch for the CIM metadata definitions [0] is defining<br>
property names in all lowercase, for example,<br>
'instructionsetextensionname' instead of 'InstructionSetExtensionName' as<br>
on an earlier patch.  In addition to being more readable, the CamelCased<br>
names are what's actually used in the CIM schema.  Lin's reason for the<br>
change is that if image consumers looking for image metadata are using the<br>
Images v1 or the Compute API, they won't find CamelCased property names<br>
among the image properties.  By keeping everything lowercase, we eliminate<br>
the problem of a developer forgetting to normalize image property names<br>
before testing for their existence.<br>
<br>
(3)  This issue impacts the work underway to convert Nova to consuming the<br>
Images v2 API.<br>
<br>
We need to formalize the intended behavior.  Here's a proposal:<br>
(a) If you use the Images v1 API or the Compute API to *set* an image<br>
property name, you get lowercase only.<br>
(b) If you use the Images v1 API or the Compute API to *get* an image<br>
proeprty name, you get lowercase only.<br>
(c) The behavior of the Compute API with respect to image property names<br>
should not change when Nova starts using the Images v2 API.<br>
(d) If you use the Images v2 API to *set* image property names, they are<br>
stored as cased in the request.<br>
(e) For the purposes of preventing duplicate image property names on a<br>
single image, property names are *case insensitive*.<br>
(f) If you use the Images v2 API to *get* image property names, you will<br>
receive them as they were stored, but you should treat them as case<br>
insensitive.<br>
<br>
This proposal is basically what we've got now, plus the recommendation<br>
that image property names be treated as case insensitive when using the<br>
Images v2 API.<br>
<br>
We need to get consensus on this quickly so that the implementation of the<br>
CIM Namespace Metadata spec [1] can be completed.  The hold up at the<br>
moment is whether the property names should be CamelCased or simply<br>
lowercased.  My opinion is that if everyone's going to make all property<br>
names lowercase just to be safe, then we ought to go ahead and enforce<br>
this in the Images API, that is, make the Images v2 API act just like the<br>
Images v1 API in this regard.<br></blockquote><div><br></div><div>I think I'd let the image API enforce this, as you've suggested. </div><div><br></div><div>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?</div><div><br></div><div>Flavio</div><div><br></div></div>-- <br><div class="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div><span style="font-size:12.8px">@flaper87</span><br></div><div>Flavio Percoco</div><div><br></div></div></div></div></div>
</div></div>