[openstack-dev] [neutron] Cross-server locking for neutron server

ZZelle zzelle at gmail.com
Wed Jul 30 17:56:58 UTC 2014


Hello,


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:

1- Do we really to populate vxlan/gre tenant pools?
  The neutron-server could also choose randomly an vxlan vni in vni_ranges
and tries to allocate it and retries until allocate success.
  I did not verify but mac address allocation should use the same
principle?
  It is efficient if used_vnis is small enough (<50%) compared to
vni_ranges size.
  I am about to propose an update of neutron.plugins.ml2.drivers.helpers[2]
in this direction.

2- Do we need to populate/update vxlan/gre tenant pools on neutron-server
restart?
  A specific command could populate/update them (neutron-db-manage populate
/ neutron-db-populate)


Any thoughts?

[1] https://review.openstack.org/#/c/101982
[2]
https://github.com/openstack/neutron/blob/master/neutron/plugins/ml2/drivers/helpers.py


Cedric
ZZelle at IRC


On Wed, Jul 30, 2014 at 7:30 PM, Jay Pipes <jaypipes at gmail.com> wrote:

> On 07/30/2014 10:05 AM, Kevin Benton wrote:
>
>> i.e. 'optimistic locking' as opposed to the 'pessimistic locking'
>> referenced in the 3rd link of the email starting the thread.
>>
>
> No, there's no locking.
>
>  On Wed, Jul 30, 2014 at 9:55 AM, Jay Pipes <jaypipes at gmail.com
>> <mailto:jaypipes at gmail.com>> wrote:
>>
>>     On 07/30/2014 09:48 AM, Doug Wiegley wrote:
>>
>>             I'd have to look at the Neutron code, but I suspect that a
>>             simple
>>             strategy of issuing the UPDATE SQL statement with a WHERE
>>             condition that
>>
>>
>>         I¹m assuming the locking is for serializing code, whereas for
>>         what you
>>         describe above, is there some reason we wouldn¹t just use a
>>         transaction?
>>
>>
>>     Because you can't do a transaction from two different threads...
>>
>>     The compare and update strategy is for avoiding the use of SELECT
>>     FOR UPDATE.
>>
>>     Best,
>>     -jay
>>
>>
>>
>>     _________________________________________________
>>     OpenStack-dev mailing list
>>     OpenStack-dev at lists.openstack.__org
>>     <mailto:OpenStack-dev at lists.openstack.org>
>>     http://lists.openstack.org/__cgi-bin/mailman/listinfo/__openstack-dev
>> <http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev>
>>
>>
>>
>>
>>
>> --
>> Kevin Benton
>>
>>
>> _______________________________________________
>> OpenStack-dev mailing list
>> OpenStack-dev at lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140730/1fa5989e/attachment.html>


More information about the OpenStack-dev mailing list