<div dir="ltr"><div><div><div><div><div><div>Hello,<br><br><br></div>I stop to improve vxlan population and remove SELECT FOR UPDATE[1] because i am not sure the current approach is the right approach to handle vxlan/gre tenant pools:<br>
<br></div>1- Do we really to populate vxlan/gre tenant pools? <br></div>  The neutron-server could also choose randomly an vxlan vni in vni_ranges and tries to allocate it and retries until allocate success.<br></div><div>
  I did not verify but mac address allocation should use the same principle? <br></div>  It is efficient if used_vnis is small enough (<50%) compared to vni_ranges size.<br></div><div>  I am about to propose an update of neutron.plugins.ml2.drivers.helpers[2] in this direction.<br>
</div><div><br></div>2- Do we need to populate/update vxlan/gre tenant pools on neutron-server restart?<br></div>  A specific command could populate/update them (neutron-db-manage populate / neutron-db-populate)<br><br><br>
Any thoughts?<br><div><div><div><div><div><div><br>[1]<span><a href="https://review.openstack.org/#/c/101982/" style="text-decoration:none" target="_blank"><span style="font-size:15px;font-family:Arial;text-decoration:underline;vertical-align:baseline;white-space:pre-wrap"> https://review.openstack.org/#/c/101982</span></a></span><br>
[2] <a href="https://github.com/openstack/neutron/blob/master/neutron/plugins/ml2/drivers/helpers.py">https://github.com/openstack/neutron/blob/master/neutron/plugins/ml2/drivers/helpers.py</a><br><br><br></div><div>Cedric<br>
</div><div>ZZelle@IRC<br></div></div></div></div></div></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Wed, Jul 30, 2014 at 7:30 PM, Jay Pipes <span dir="ltr"><<a href="mailto:jaypipes@gmail.com" target="_blank">jaypipes@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="">On 07/30/2014 10:05 AM, Kevin Benton wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
i.e. 'optimistic locking' as opposed to the 'pessimistic locking'<br>
referenced in the 3rd link of the email starting the thread.<br>
</blockquote>
<br></div>
No, there's no locking.<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="">
On Wed, Jul 30, 2014 at 9:55 AM, Jay Pipes <<a href="mailto:jaypipes@gmail.com" target="_blank">jaypipes@gmail.com</a><br></div><div class="">
<mailto:<a href="mailto:jaypipes@gmail.com" target="_blank">jaypipes@gmail.com</a>>> wrote:<br>
<br>
    On 07/30/2014 09:48 AM, Doug Wiegley wrote:<br>
<br>
            I'd have to look at the Neutron code, but I suspect that a<br>
            simple<br>
            strategy of issuing the UPDATE SQL statement with a WHERE<br>
            condition that<br>
<br>
<br>
        Iım assuming the locking is for serializing code, whereas for<br>
        what you<br>
        describe above, is there some reason we wouldnıt just use a<br>
        transaction?<br>
<br>
<br>
    Because you can't do a transaction from two different threads...<br>
<br>
    The compare and update strategy is for avoiding the use of SELECT<br>
    FOR UPDATE.<br>
<br>
    Best,<br>
    -jay<br>
<br>
<br>
<br></div>
    ______________________________<u></u>___________________<br>
    OpenStack-dev mailing list<br>
    OpenStack-dev@lists.openstack.<u></u>__org<br>
    <mailto:<a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">OpenStack-dev@lists.<u></u>openstack.org</a>><br>
    <a href="http://lists.openstack.org/__cgi-bin/mailman/listinfo/__openstack-dev" target="_blank">http://lists.openstack.org/__<u></u>cgi-bin/mailman/listinfo/__<u></u>openstack-dev</a> <<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/<u></u>cgi-bin/mailman/listinfo/<u></u>openstack-dev</a>><div class="">
<br>
<br>
<br>
<br>
<br>
--<br>
Kevin Benton<br>
<br>
<br>
______________________________<u></u>_________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">OpenStack-dev@lists.openstack.<u></u>org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/<u></u>cgi-bin/mailman/listinfo/<u></u>openstack-dev</a><br>
<br>
</div></blockquote><div class="HOEnZb"><div class="h5">
<br>
<br>
______________________________<u></u>_________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">OpenStack-dev@lists.openstack.<u></u>org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/<u></u>cgi-bin/mailman/listinfo/<u></u>openstack-dev</a><br>
</div></div></blockquote></div><br></div>