On Thu, Feb 25, 2016 at 2:53 AM, Brian Rosmaita < brian.rosma...@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
__________________________________________________________________________ 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
