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 <mriede...@gmail.com>: > On 3/27/2017 9:59 AM, Duncan Thomas wrote: > >> On 27 March 2017 at 14:20, 王玺源 <wangxiyuan1...@gmail.com >> <mailto:wangxiyuan1...@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.mcgin...@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-requ...@lists.openstack.org?subject:unsubscribe >> <http://openstack-dev-requ...@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-requ...@lists.openstack.org?subject:unsubscribe >> <http://openstack-dev-requ...@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-requ...@lists.openstack.org?subject:unsubscribe >> <http://openstack-dev-requ...@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-requ...@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-requ...@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-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
