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@IRC On Wed, Jul 30, 2014 at 7:30 PM, Jay Pipes <jaypi...@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 <jaypi...@gmail.com >> <mailto:jaypi...@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@lists.openstack.__org >> <mailto:OpenStack-dev@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@lists.openstack.org >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> >> > > _______________________________________________ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >
_______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev