[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