Open Stack

Jay Pipes <jaypipes at gmail.com> wrote on 20/04/2014 15:05:51:

> From: Jay Pipes <jaypipes at gmail.com>
> To: openstack-dev at 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 at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev