<div dir="ltr"><div>We have an user demand that volumes should be filtered by some operation with metadata(or tag):</div><div><span style="color:rgb(0,0,0);font-family:微软雅黑;font-size:14px;line-height:normal;white-space:pre-wrap;background-color:rgb(247,247,247)">1. key1=value1</span><br style="font-family:arial,"microsoft yahei";color:rgb(0,0,0);font-size:14px;line-height:normal;white-space:pre-wrap;background-color:rgb(247,247,247)"><span style="color:rgb(0,0,0);font-family:微软雅黑;font-size:14px;line-height:normal;white-space:pre-wrap;background-color:rgb(247,247,247)">2. key1=value1 and key2=value2</span><br style="font-family:arial,"microsoft yahei";color:rgb(0,0,0);font-size:14px;line-height:normal;white-space:pre-wrap;background-color:rgb(247,247,247)"><span style="color:rgb(0,0,0);font-family:微软雅黑;font-size:14px;line-height:normal;white-space:pre-wrap;background-color:rgb(247,247,247)">3. key1=value1 or key1=value2</span><br style="font-family:arial,"microsoft yahei";color:rgb(0,0,0);font-size:14px;line-height:normal;white-space:pre-wrap;background-color:rgb(247,247,247)"><span style="color:rgb(0,0,0);font-family:微软雅黑;font-size:14px;line-height:normal;white-space:pre-wrap;background-color:rgb(247,247,247)">4. key1=value1 or key2=value2</span><br style="font-family:arial,"microsoft yahei";color:rgb(0,0,0);font-size:14px;line-height:normal;white-space:pre-wrap;background-color:rgb(247,247,247)"><span style="color:rgb(0,0,0);font-family:微软雅黑;font-size:14px;line-height:normal;white-space:pre-wrap;background-color:rgb(247,247,247)">5. not key1=value1</span><br style="font-family:arial,"microsoft yahei";color:rgb(0,0,0);font-size:14px;line-height:normal;white-space:pre-wrap;background-color:rgb(247,247,247)"><span style="color:rgb(0,0,0);font-family:微软雅黑;font-size:14px;line-height:normal;white-space:pre-wrap;background-color:rgb(247,247,247)">6. not key1=value1 and not key1=value2</span><br style="font-family:arial,"microsoft yahei";color:rgb(0,0,0);font-size:14px;line-height:normal;white-space:pre-wrap;background-color:rgb(247,247,247)"><span style="color:rgb(0,0,0);font-family:微软雅黑;font-size:14px;line-height:normal;white-space:pre-wrap;background-color:rgb(247,247,247)">7. not key1=value1 and not key2=value2</span><br style="font-family:arial,"microsoft yahei";color:rgb(0,0,0);font-size:14px;line-height:normal;white-space:pre-wrap;background-color:rgb(247,247,247)"><span style="color:rgb(0,0,0);font-family:微软雅黑;font-size:14px;line-height:normal;white-space:pre-wrap;background-color:rgb(247,247,247)">8. not key1=value1 and key2=value2</span><br style="font-family:arial,"microsoft yahei";color:rgb(0,0,0);font-size:14px;line-height:normal;white-space:pre-wrap;background-color:rgb(247,247,247)"><br></div>But AFAIK Cinder now use metadata as a filter when list volumes, so it only support the 1 and 2.<div><br></div><div>Is there any suggestion that how Cinder can support them?<br></div><div><br></div><div><br></div><div>Thanks</div><div>Wangxiyuan</div></div><div class="gmail_extra"><br><div class="gmail_quote">2017-04-08 8:49 GMT+08:00 Matt Riedemann <span dir="ltr"><<a href="mailto:mriedemos@gmail.com" target="_blank">mriedemos@gmail.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On 3/27/2017 9:59 AM, Duncan Thomas wrote:<br>
</span><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">
On 27 March 2017 at 14:20, 王玺源 <<a href="mailto:wangxiyuan1007@gmail.com" target="_blank">wangxiyuan1007@gmail.com</a><br></span><div><div class="h5">
<mailto:<a href="mailto:wangxiyuan1007@gmail.com" target="_blank">wangxiyuan1007@gmail.c<wbr>om</a>>> wrote:<br>
<br>
    I think the reason is quite simple:<br>
    1. Some users don't want to use key/value pairs to tag volums. They<br>
    just need some simple strings.<br>
<br>
<br>
...and some do. We can hide this in the client and just save tags under<br>
a metadata item called 'tags', with no API changes needed on the cinder<br>
side and backwards compatability on the client.<br>
<br>
<br>
    2. Metadata must be shorter than 255. If users don't need keys, use<br>
    tag here can save some spaces.<br>
<br>
<br>
How many / long tags are you considering supporting?<br>
<br>
<br>
    3. Easy for quick searching or filter. Users don't need to know<br>
    what' the key related to the value.<br>
<br>
<br>
The client can hide all this, so it is not really a justification<br>
<br>
<br>
    4. For Web App, it should be a basic function[1]<br>
<br>
<br>
Web standards are not really standards. You can find a million things<br>
that apps 'should' do. They're usually contradictory.<br>
<br>
<br>
<br>
<br>
    [1]<a href="https://en.m.wikipedia.org/wiki/Tag_(metadata)" rel="noreferrer" target="_blank">https://en.m.wikipedia.org/<wbr>wiki/Tag_(metadata)</a><br>
    <<a href="https://en.m.wikipedia.org/wiki/Tag_(metadata)" rel="noreferrer" target="_blank">https://en.m.wikipedia.org/wi<wbr>ki/Tag_(metadata)</a>><br>
<br>
<br>
    2017-03-27 19:49 GMT+08:00 Sean McGinnis <<a href="mailto:sean.mcginnis@gmx.com" target="_blank">sean.mcginnis@gmx.com</a>>:<br>
<br>
        On Mon, Mar 27, 2017 at 03:13:59PM +0800, 王玺源 wrote:<br>
        > Hi cinder team:<br>
        ><br>
        >     I want to know what's your thought about adding tags for volumes.<br>
        ><br>
        >     Now Many resources, like Nova instances, Glance images, Neutron<br>
        > networks and so on, all support tagging. And some of our cloud customers<br>
        > want this feature in Cinder as well. It's useful for auditing, billing for<br>
        > could admin, it can let admin and users filter resources by tag, it can let<br>
        > users categorize resources for different usage or just remarks something.<br>
        ><br>
        >     Actually there is a related spec in Cinder 2 years ago, but<br>
        > unfortunately it was not accepted and was abandoned :<br>
        > <a href="https://review.openstack.org/#/c/99305/" rel="noreferrer" target="_blank">https://review.openstack.org/#<wbr>/c/99305/</a><br>
        <<a href="https://review.openstack.org/#/c/99305/" rel="noreferrer" target="_blank">https://review.openstack.org/<wbr>#/c/99305/</a>><br>
        ><br>
        >     Can we bring it up and revisit it a second time now? What's cinder<br>
        > team's idea?  Can you give me some advice that if we can do it or not?<br>
<br>
        Can you give any reason why the existing metadata mechanism does<br>
        not or will<br>
        not work for them? There was some discussion in that spec<br>
        explaining why it<br>
        was rejected at the time. I don't think anything has changed<br>
        since then that<br>
        would change what was said there.<br>
<br>
        ><br>
        ><br>
        > Thanks!<br>
        ><br>
        > Wangxiyuan<br>
<br>
        ><br>
        ______________________________<wbr>______________________________<wbr>______________<br>
        > OpenStack Development Mailing List (not for usage questions)<br>
        > Unsubscribe:<br>
        <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.op<wbr>enstack.org?subject:unsubscrib<wbr>e</a><br></div></div>
        <<a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">http://OpenStack-dev-request@<wbr>lists.openstack.org?subject:un<wbr>subscribe</a>><br>
        ><br>
        <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi<wbr>-bin/mailman/listinfo/openstac<wbr>k-dev</a> <<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cg<wbr>i-bin/mailman/listinfo/opensta<wbr>ck-dev</a>><span class=""><br>
<br>
<br>
        ______________________________<wbr>______________________________<wbr>______________<br>
        OpenStack Development Mailing List (not for usage questions)<br>
        Unsubscribe:<br>
        <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.op<wbr>enstack.org?subject:unsubscrib<wbr>e</a><br></span>
        <<a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">http://OpenStack-dev-request@<wbr>lists.openstack.org?subject:un<wbr>subscribe</a>><br>
        <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi<wbr>-bin/mailman/listinfo/openstac<wbr>k-dev</a> <<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cg<wbr>i-bin/mailman/listinfo/opensta<wbr>ck-dev</a>><span class=""><br>
<br>
<br>
<br>
    ______________________________<wbr>______________________________<wbr>______________<br>
    OpenStack Development Mailing List (not for usage questions)<br>
    Unsubscribe:<br>
    <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.op<wbr>enstack.org?subject:unsubscrib<wbr>e</a><br></span>
    <<a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">http://OpenStack-dev-request@<wbr>lists.openstack.org?subject:un<wbr>subscribe</a>><br>
    <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi<wbr>-bin/mailman/listinfo/openstac<wbr>k-dev</a><span class=""><br>
    <<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cg<wbr>i-bin/mailman/listinfo/opensta<wbr>ck-dev</a>><br>
<br>
<br>
<br>
<br>
--<br>
--<br>
Duncan Thomas<br>
<br>
<br></span><span class="">
______________________________<wbr>______________________________<wbr>______________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.op<wbr>enstack.org?subject:unsubscrib<wbr>e</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi<wbr>-bin/mailman/listinfo/openstac<wbr>k-dev</a><br>
<br>
</span></blockquote>
<br>
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.<br>
<br>
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.<br>
<br>
The nova spec discusses metadata as an alternative if you're interested:<br>
<br>
<a href="https://specs.openstack.org/openstack/nova-specs/specs/newton/implemented/tag-instances.html" rel="noreferrer" target="_blank">https://specs.openstack.org/op<wbr>enstack/nova-specs/specs/newto<wbr>n/implemented/tag-instances.<wbr>html</a><span class="HOEnZb"><font color="#888888"><br>
<br>
-- <br>
<br>
Thanks,<br>
<br>
Matt</font></span><div class="HOEnZb"><div class="h5"><br>
<br>
______________________________<wbr>______________________________<wbr>______________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.op<wbr>enstack.org?subject:unsubscrib<wbr>e</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi<wbr>-bin/mailman/listinfo/openstac<wbr>k-dev</a><br>
</div></div></blockquote></div><br></div>