Open Stack

You can deploy Searchlight
(https://wiki.openstack.org/wiki/Searchlight) and it can handle this
and more complex metadata querying (it is backed by elastic search and
supports all of the expressive power of elastic search queries).
There's a limit to how much query functionality can go into a basic
API service before DoS becomes a serious issue, or you start to
require serious database restructuring.

As an extreme example, I've repeated resisted attempts to add regexp
matching into the cinder API since nobody has come up with any way to
deal with the DoS issues - I suspect the regexp processing in nova is
vulnerable though I've never spent the time to prove it.

On 10 April 2017 at 10:58, 王玺源 <wangxiyuan1007 at gmail.com> wrote:
> 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:unsubscribe>
>>>         >
>>>         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>
>>>
>>>
>>>
>>>
>>> __________________________________________________________________________
>>>     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:unsubscribe
>>> 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/newton/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
>
>
>
> __________________________________________________________________________
> 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