On 27 March 2017 at 14:20, 王玺源 <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) > > > 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/ >> > >> > 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.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-requ...@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-requ...@lists.openstack.org?subject:unsubscribe > 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:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev