Open Stack

On 27 March 2017 at 14:20, 王玺源 <wangxiyuan1007 at gmail.com> wrote:

> I think the reason is quite simple:
> 1. Some users don't want to use key/value pairs to tag volums. They just
> need some simple strings.
>

...and some do. We can hide this in the client and just save tags under a
metadata item called 'tags', with no API changes needed on the cinder side
and backwards compatability on the client.


> 2. Metadata must be shorter than 255. If users don't need keys, use tag
> here can save some spaces.
>

How many / long tags are you considering supporting?


> 3. Easy for quick searching or filter. Users don't need to know what' the
> key related to the value.
>

The client can hide all this, so it is not really a justification


> 4. For Web App, it should be a basic function[1]
>

Web standards are not really standards. You can find a million things that
apps 'should' do. They're usually contradictory.



>
> [1]https://en.m.wikipedia.org/wiki/Tag_(metadata)
>
>
> 2017-03-27 19:49 GMT+08:00 Sean McGinnis <sean.mcginnis at gmx.com>:
>
>> On Mon, Mar 27, 2017 at 03:13:59PM +0800, 王玺源 wrote:
>> > Hi cinder team:
>> >
>> >     I want to know what's your thought about adding tags for volumes.
>> >
>> >     Now Many resources, like Nova instances, Glance images, Neutron
>> > networks and so on, all support tagging. And some of our cloud customers
>> > want this feature in Cinder as well. It's useful for auditing, billing
>> for
>> > could admin, it can let admin and users filter resources by tag, it can
>> let
>> > users categorize resources for different usage or just remarks
>> something.
>> >
>> >     Actually there is a related spec in Cinder 2 years ago, but
>> > unfortunately it was not accepted and was abandoned :
>> > https://review.openstack.org/#/c/99305/
>> >
>> >     Can we bring it up and revisit it a second time now? What's cinder
>> > team's idea?  Can you give me some advice that if we can do it or not?
>>
>> Can you give any reason why the existing metadata mechanism does not or
>> will
>> not work for them? There was some discussion in that spec explaining why
>> it
>> was rejected at the time. I don't think anything has changed since then
>> that
>> would change what was said there.
>>
>> >
>> >
>> > Thanks!
>> >
>> > Wangxiyuan
>>
>> > ____________________________________________________________
>> ______________
>> > OpenStack Development Mailing List (not for usage questions)
>> > Unsubscribe: OpenStack-dev-request at lists.op
>> enstack.org?subject:unsubscribe
>> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>> ____________________________________________________________
>> ______________
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscrib
>> e
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>


-- 
-- 
Duncan Thomas
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20170327/caa3f815/attachment.html>