<div dir="ltr">Do we really need any of these locks?  I'm sure we could come up with some way to remove them, rather than make them distributed.</div><div class="gmail_extra"><br><div class="gmail_quote">On Sun, Jun 28, 2015 at 5:07 AM, Joshua Harlow <span dir="ltr"><<a href="mailto:harlowja@outlook.com" target="_blank">harlowja@outlook.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">John Griffith wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">
<br>
<br>
On Sat, Jun 27, 2015 at 11:47 AM, Joshua Harlow <<a href="mailto:harlowja@outlook.com" target="_blank">harlowja@outlook.com</a><br></span><div><div class="h5">
<mailto:<a href="mailto:harlowja@outlook.com" target="_blank">harlowja@outlook.com</a>>> wrote:<br>
<br>
    Duncan Thomas wrote:<br>
<br>
        We are working on some sort of distributed replacement for the<br>
        locks in<br>
        cinder, since file locks are limiting our ability to do HA. I'm<br>
        afraid<br>
        you're unlikely to get any traction until that work is done.<br>
<br>
        I also have a concern that some backend do not handle load well,<br>
        and so<br>
        benefit from the current serialisation. It might be necessary to<br>
        push<br>
        this lock down into the driver and allow each driver to choose it's<br>
        locking model for snapshots.<br>
<br>
<br>
    IMHO (and I know this isn't what everyone thinks) but I'd rather<br>
    have cinder (and other projects) be like this from top gear (<br>
    <a href="https://www.youtube.com/watch?v=xnWKz7Cthkk" rel="noreferrer" target="_blank">https://www.youtube.com/watch?v=xnWKz7Cthkk</a> ) where that toyota<br>
    truck is virtually indestructible vs. trying to be a<br>
    high-maintenance ferrari (when most openstack projects do a bad job<br>
    of trying to be one). So, maybe for a time (and I may regret saying<br>
    this) we could consider focusing on reliability, consistency, being<br>
    the toyota vs. handling some arbitrary amount of load (trying to be<br>
    a ferrari).<br>
<br>
    Also I'd expect/think operators would rather prefer a toyota at this<br>
    stage of openstack :) Ok enough analogies, ha.<br>
<br>
<br>
​Well said Josh, I guess I've been going about this all wrong by not<br>
using the analogies :)​<br>
</div></div></blockquote>
<br>
Exactly!! IMHO should be the new 'openstack mantra, built from components/projects that survive like a toyota truck' haha. Part 2 (<a href="https://www.youtube.com/watch?v=xTPnIpjodA8" rel="noreferrer" target="_blank">https://www.youtube.com/watch?v=xTPnIpjodA8</a>) and part 3 (<a href="https://www.youtube.com/watch?v=kFnVZXQD5_k" rel="noreferrer" target="_blank">https://www.youtube.com/watch?v=kFnVZXQD5_k</a>) are funny/interesting also :-P<br>
<br>
Now we just need openstack to be that reliable and tolerant of failures/calamities/...<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">
<br>
<br>
    -Josh<br>
<br>
<br>
        On 27 Jun 2015 06:18, "niuzhenguo" <<a href="mailto:niuzhenguo@huawei.com" target="_blank">niuzhenguo@huawei.com</a><br>
        <mailto:<a href="mailto:niuzhenguo@huawei.com" target="_blank">niuzhenguo@huawei.com</a>><br></span>
        <mailto:<a href="mailto:niuzhenguo@huawei.com" target="_blank">niuzhenguo@huawei.com</a> <mailto:<a href="mailto:niuzhenguo@huawei.com" target="_blank">niuzhenguo@huawei.com</a>>>><div><div class="h5"><br>
        wrote:<br>
<br>
             Hi folks,____<br>
<br>
             __ __<br>
<br>
             Currently we use a lockfile to protect the create<br>
        operations from<br>
             concurrent delete the source volume/snapshot, we use<br>
        exclusive____<br>
<br>
             locks on both delete and create sides which will ensure<br>
        that:____<br>
<br>
             __ __<br>
<br>
             __1.__If a create of VolA from snap/VolB is in progress,<br>
        any delete<br>
             requests for snap/VolB will wait until the create is<br>
        complete.____<br>
<br>
             __2.__If a delete of snap/VolA is in progress, any create from<br>
             snap/VolA will wait until snap/VolA delete is complte.____<br>
<br>
             __ __<br>
<br>
             but, the exclusive locks will also result in:____<br>
<br>
             __ __<br>
<br>
             __3.__If a create of VolA from snap/VolB is inprogress, any<br>
        other<br>
             create requests from snap/VolB will wait until the create is<br>
             complete. ____<br>
<br>
             __ __<br>
<br>
             So the create operations from same volume/snapshot can not<br>
        process<br>
             on parallel, please reference bp [1].____<br>
<br>
             I’d like to change the current filelock or introduce a new<br>
        lock to<br>
             oslo.concurrency.____<br>
<br>
             __ __<br>
<br>
             Proposed change:____<br>
<br>
             Add exclusive(write) locks for delete operations and<br>
        shared(read)<br>
             locks for create operations, to ensure that create from<br>
             volume/snapshot____<br>
<br>
             can work on parallel and protect create operations from<br>
        concurrent<br>
             delete the source volume/snapshot.____<br>
<br>
             __ __<br>
<br>
             I’d like to get what’s your suggestions, thanks in advance.____<br>
<br>
             __ __<br>
<br>
             [1]<br>
        <a href="https://blueprints.launchpad.net/cinder/+spec/enhance-locks____" rel="noreferrer" target="_blank">https://blueprints.launchpad.net/cinder/+spec/enhance-locks____</a><br>
<br>
             __ __<br>
<br>
             __ __<br>
<br>
             -zhenguo____<br>
<br>
<br>
<br>
        __________________________________________________________________________<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.openstack.org?subject:unsubscribe</a><br>
        <<a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a>><br>
        <<a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a>><br>
        <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br>
        __________________________________________________________________________<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.openstack.org?subject:unsubscribe</a><br>
        <<a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a>><br>
        <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br>
<br>
    __________________________________________________________________________<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.openstack.org?subject:unsubscribe</a><br>
    <<a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a>><br>
    <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br>
<br>
__________________________________________________________________________<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.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</div></div></blockquote><div class="HOEnZb"><div class="h5">
<br>
__________________________________________________________________________<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.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><b style="font-size:12.7272720336914px"><font color="#666666">Avishay Traeger</font></b><br></div><div><i><font color="#666666">Storage R&D</font></i></div><div><span style="color:rgb(102,102,102);font-size:12.7272720336914px"><br></span></div><div><span style="color:rgb(102,102,102)">Mobile:</span><span style="color:rgb(102,102,102)"> </span><a value="+972524317955" style="color:rgb(17,85,204)">+972 54 447 1475</a><br></div><div><font color="#666666">E-mail: <a href="mailto:avishay@stratoscale.com" style="color:rgb(17,85,204)" target="_blank">avishay@stratoscale.com</a></font></div><div><font color="#666666"><br></font></div><div><img src="http://www.stratoscale.com/wp-content/uploads/Logo-Signature-Stratoscale-230.jpg"><br></div><div><font color="#666666"><br></font></div><div><p style="margin:0in"><a href="http://www.stratoscale.com/" style="color:rgb(17,85,204)" target="_blank"><span style="font-family:arial;font-size:9.75pt">Web</span></a><span style="font-family:arial;font-size:9.75pt"> | </span><a href="http://www.stratoscale.com/blog/" style="color:rgb(17,85,204)" target="_blank"><span style="font-family:arial;font-size:9.75pt">Blog</span></a><span style="font-family:arial;font-size:9.75pt;color:rgb(108,163,214)"> | </span><a href="https://twitter.com/Stratoscale" style="color:rgb(17,85,204)" target="_blank"><span style="font-family:arial;font-size:9.75pt">Twitter</span></a><span style="font-family:arial;font-size:9.75pt;color:rgb(108,163,214)"> | <a href="https://plus.google.com/u/1/b/108421603458396133912/108421603458396133912/posts" style="color:rgb(17,85,204)" target="_blank">Google+</a> | </span><span style="font-family:arial;font-size:9.75pt"><a href="https://www.linkedin.com/company/stratoscale" style="color:rgb(17,85,204)" target="_blank">Linkedin</a></span></p></div></div></div></div></div></div></div>
</div>