Re: [openstack-dev] 答复: [Nova][Neutron][Cinder][Heat]Should we support tags for os resources?

2014-04-21 Thread Jay Pipes
On Mon, 2014-04-21 at 13:15 -0700, Vijay B wrote:
> Hi Tianhua, Jay,
> 
> 
> A blueprint has already been submitted in this regard:
> 
> 
> https://docs.google.com/document/d/1ZqW7qeyHTm9AQt28GUdfv46ui9mz09UQNvjXiewOAys/edit#
> 
> 
> 
> We've been working to implement a generic tagging framework where tags
> are a first class resource and other resources can be associated with
> tags. Our first implementation focuses on neutron. For us at Ebay,
> this forms an important foundational framework to support
> flexible/customizable VPC architectures. A detailed design with
> extension/db/other changes has been drawn up and will be submitted for
> review to the group in the near future. Please do add your
> thoughts/reviews to it.

Hi Vijay,

Please see my first comment on the above document. Tags are single
strings, not key/value pairs.

IMO, tags are also a **user-controlled** annotation of an object. What
you are describing in that proposal seems more to be
**system-controlled** annotation of objects using key/value
properties...

Best,
-jay

> 
> On Mon, Apr 21, 2014 at 12:46 PM, Jay Pipes 
> wrote:
> Absolutely. Feel free.
> 
> 
> On Mon, Apr 21, 2014 at 4:48 AM, Huangtianhua
>  wrote:
> I plan to register a blueprints in nova for record
> this. Can I?
> 
> 
> -邮件原件-
> 发件人: Jay Pipes [mailto:jaypi...@gmail.com]
> 发送时间: 2014年4月20日 21:06
> 收件人: 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 +, 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

Re: [openstack-dev] 答复: [Nova][Neutron][Cinder][Heat]Should we support tags for os resources?

2014-04-21 Thread Vijay B
Hi Tianhua, Jay,

A blueprint has already been submitted in this regard:

https://docs.google.com/document/d/1ZqW7qeyHTm9AQt28GUdfv46ui9mz09UQNvjXiewOAys/edit#

We've been working to implement a generic tagging framework where tags are
a first class resource and other resources can be associated with tags. Our
first implementation focuses on neutron. For us at Ebay, this forms an
important foundational framework to support flexible/customizable VPC
architectures. A detailed design with extension/db/other changes has been
drawn up and will be submitted for review to the group in the near future.
Please do add your thoughts/reviews to it.

Regards,
Vijay


On Mon, Apr 21, 2014 at 12:46 PM, Jay Pipes  wrote:

> Absolutely. Feel free.
>
>
> On Mon, Apr 21, 2014 at 4:48 AM, Huangtianhua wrote:
>
>> I plan to register a blueprints in nova for record this. Can I?
>>
>>
>> -邮件原件-
>> 发件人: Jay Pipes [mailto:jaypi...@gmail.com]
>> 发送时间: 2014年4月20日 21:06
>> 收件人: 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 +, 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
>> ___
>> 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?

2014-04-21 Thread Jay Pipes
Absolutely. Feel free.


On Mon, Apr 21, 2014 at 4:48 AM, Huangtianhua wrote:

> I plan to register a blueprints in nova for record this. Can I?
>
>
> -邮件原件-
> 发件人: Jay Pipes [mailto:jaypi...@gmail.com]
> 发送时间: 2014年4月20日 21:06
> 收件人: 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 +, 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
> ___
> 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