Thanks very much. I have register the blueprints for nova. https://blueprints.launchpad.net/nova/+spec/add-tags-for-os-resources
The simple plan is: 1. Add the tags api (create tags/delete tags/describe tags) for v3 api 2. Change the implement for instance from “metadata” to “tags” Your suggestions? Thanks 发件人: Jay Pipes [mailto:jaypi...@gmail.com] 发送时间: 2014年4月22日 3:46 收件人: OpenStack Development Mailing List (not for usage questions) 主题: Re: [openstack-dev] 答复: [Nova][Neutron][Cinder][Heat]Should we support tags for os resources? Absolutely. Feel free. On Mon, Apr 21, 2014 at 4:48 AM, Huangtianhua <huangtian...@huawei.com<mailto:huangtian...@huawei.com>> wrote: I plan to register a blueprints in nova for record this. Can I? -----邮件原件----- 发件人: Jay Pipes [mailto:jaypi...@gmail.com<mailto:jaypi...@gmail.com>] 发送时间: 2014年4月20日 21:06 收件人: openstack-dev@lists.openstack.org<mailto:openstack-dev@lists.openstack.org> 主题: 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. 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<mailto:OpenStack-dev@lists.openstack.org> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org<mailto: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
