Re: [openstack-dev] [Nova][Neutron][Cinder][Heat]Should we support tags for os resources?
Excerpts from Jay Pipes' jaypi...@gmail.com message on 23/04/2014 01:43:42: On Tue, 2014-04-22 at 13:14 +0200, Thomas Spatzier wrote: snip * 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? I'd rather have the common ones in the resource schema itself, since that is, IMHO, better practice for enforcing consistency and type safety. +1, that's what I would prefer as well, but I wanted to make sure you mean the same. 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. Zactly :) As long as properties are just custom properties, we would require a lot of discipline from every to maintain properties correctly. Yep, and you'd need to keep in sync with the code in Nova that currently maintains these properties. :) Best, -jay 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 ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Nova][Neutron][Cinder][Heat]Should we support tags for os resources?
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 +, 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
Re: [openstack-dev] [Nova][Neutron][Cinder][Heat]Should we support tags for os resources?
On Tue, 2014-04-22 at 13:14 +0200, Thomas Spatzier wrote: snip * 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? I'd rather have the common ones in the resource schema itself, since that is, IMHO, better practice for enforcing consistency and type safety. 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. Zactly :) As long as properties are just custom properties, we would require a lot of discipline from every to maintain properties correctly. Yep, and you'd need to keep in sync with the code in Nova that currently maintains these properties. :) Best, -jay 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 ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Nova][Neutron][Cinder][Heat]Should we support tags for os resources?
On Sun, 2014-04-20 at 08:35 +, 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. 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: * 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) * 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. * 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. Best, -jay ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
