Jay Pipes <jaypi...@gmail.com> wrote on 20/04/2014 15:05:51: > From: Jay Pipes <jaypi...@gmail.com> > To: openstack-dev@lists.openstack.org > Date: 20/04/2014 15:07 > Subject: Re: [openstack-dev] [Nova][Neutron][Cinder][Heat]Should we > support tags for os resources? > > On Sun, 2014-04-20 at 08:35 +0000, Huangtianhua wrote: > > Hi all: > > > > Currently, the EC2 API of OpenStack only has tags support (metadata) > > for instances. And there has already a blueprint about to add support > > for volumes and volume snapshots using “metadata”. > > > > There are a lot of resources such as > > image/subnet/securityGroup/networkInterface(port) are supported add > > tags for AWS. > > > > I think we should support tags for these resources. There may be no > > property “metadata" for these resources, so we should to add > > “metadata” to support the resource tags, the change related API. > > Hi Tianhua, > > In OpenStack, generally, the choice was made to use maps of key/value > pairs instead of lists of strings (tags) to annotate objects exposed in > the REST APIs. OpenStack REST APIs inconsistently call these maps of > key/value pairs: > > * "properties" (Glance, Cinder Image, Volume respectively) > * "extra_specs" (Nova InstanceType) > * "metadata" (Nova Instance, Aggregate and InstanceGroup, Neutron) > * "metadetails" (Nova Aggregate and InstanceGroup) > * "system_metadata" (Nova Instance -- differs from "normal" metadata in > that the key/value pairs are 'owned' by Nova, not a user...) > > Personally, I think tags are a cleaner way of annotating objects when > the annotation is coming from a normal user. Tags represent by far the > most common way for REST APIs to enable user-facing annotation of > objects in a way that is easy to search on. I'd love to see support for > tags added to any searchable/queryable object in all of the OpenStack > APIs.
Fully agree. Tags should be something a normal end user can use to make the objects he is working with searchable for his purposes. And this is likely something different from system-controlled properties that _all_ users (not the one specific end user) can rely on. > > I'd also like to see cleanup of the aforementioned inconsistencies in > how maps of key/value pairs are both implemented and named throughout > the OpenStack APIs. Specifically, I'd like to see this implemented in > the next major version of the Compute API: +1 on making this uniform across the various projects. This would make it much more intuitive. > > * Removal of the "metadetails" term > * All key/value pairs can only be changed by users with elevated > privileged system-controlled (normal users should use tags) +1 on this, because this would be data that other users or projects rely on - see also my use case below. > * Call all these key/value pair combinations "properties" -- > technically, "metadata" is "data about data", like the size of an > integer. These key/value pairs are just data, not data about data. +1 on "properties" > * Identify key/value pairs that are relied on by all of Nova to be a > specific key and value combination, and make these things actual real > attributes on some object model -- since that is a much greater guard > for the schema of an object and enables greater performance by allowing > both type safety of the underlying data and removes the need to search > by both a key and a value. Makes a lot of sense to me. So are you suggesting to have a set of well-defined property names per resource but still store them in the properties name-value map? Or would you rather make those part of the resource schema? BTW, here is a use case in the context of which we have been thinking about that topic: we opened a BP for allowing constraint based selection of images for Heat templates, i.e. instead of saying something like (using pseudo template language) "image ID must be in [fedora-19-x86_64, fedora-20-x86_64]" say something like "architecture must be x86_64, distro must be fedora, version must be between 19 and 20" (see also [1]). This of course would require the existence of well-defined properties in glance so an image selection query in Heat can work. As long as properties are "just" custom properties, we would require a lot of discipline from every to maintain properties correctly. And the implementation in Heat could be kind of tolerant, i.e. give it a try, and if the query fails just fail the stack creation. But if this is likely to happen in 90% of all environments, the usefulness is questionable. Here is a link to the BP I mentioned: [1] https://blueprints.launchpad.net/heat/+spec/constraint-based-flavors-and-images Regards, Thomas > > Best, > -jay > > > > _______________________________________________ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
