Open Stack

We have an user demand that volumes should be filtered by some operation
with metadata(or tag):
1. key1=value1
2. key1=value1 and key2=value2
3. key1=value1 or key1=value2
4. key1=value1 or key2=value2
5. not key1=value1
6. not key1=value1 and not key1=value2
7. not key1=value1 and not key2=value2
8. not key1=value1 and key2=value2

But AFAIK Cinder now use metadata as a filter when list volumes, so it only
support the 1 and 2.

Is there any suggestion that how Cinder can support them?


Thanks
Wangxiyuan

2017-04-08 8:49 GMT+08:00 Matt Riedemann <mriedemos at gmail.com>:

> On 3/27/2017 9:59 AM, Duncan Thomas wrote:
>
>> On 27 March 2017 at 14:20, 王玺源 <wangxiyuan1007 at gmail.com
>> <mailto: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)
>>     <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/
>>         <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.openstack.org?subject:unsubscribe
>>         <http://OpenStack-dev-request@lists.openstack.org?subject:un
>> subscribe>
>>         >
>>         http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>> <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://OpenStack-dev-request@lists.openstack.org?subject:un
>> subscribe>
>>         http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>> <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://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
>> >
>>     http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>     <http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev>
>>
>>
>>
>>
>> --
>> --
>> Duncan Thomas
>>
>>
>> ____________________________________________________________
>> ______________
>> 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
>>
>>
> Duncan, which client are you referring to? python-cinderclient? Or are you
> suggesting duplicating that client-side logic in every client library
> available in the ecosystem.
>
> I brought up the same questions about using metadata when we added server
> tags support to nova, and it's just too heavy weight in this case when all
> you want is a dumb simple little tag.
>
> The nova spec discusses metadata as an alternative if you're interested:
>
> https://specs.openstack.org/openstack/nova-specs/specs/newto
> n/implemented/tag-instances.html
>
> --
>
> Thanks,
>
> Matt
>
>
> __________________________________________________________________________
> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20170410/bd161717/attachment.html>