Concurrent DHCP agent updates can result in a DB lock
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
neutron |
Fix Released
|
Medium
|
Rodolfo Alonso |
Bug Description
Bugzilla reference: https:/
When a new network and the first subnet are created, the DHCP agent is updated. The agent scheduler increases the DHCP agent register "load" [1] field that will be used to schedule new networks into the same agent.
If multiple concurrent networks (and the first subnet) are created, the agent "load" will be modified concurrently. The DB guarantees that only one transaction can increase the agent "load" parameter at once; the other transactions will fail and retried again. E.g.: https:/
NOTE: when I say network and the first subnet is because that will trigger the spawn of a new dnsmasq process. This is the event that increases +1 the "load" value. Any other new subnet added to this network will modify the dnsmasq config but won't increase the "load" value.
As commented in the "BaseResourceFi
This bug proposes to catch the DB errors in "BaseResourceFi
[1]https:/
[2]https:/
Changed in neutron: | |
assignee: | nobody → Rodolfo Alonso (rodolfo-alonso-hernandez) |
description: | updated |
Changed in neutron: | |
importance: | Undecided → Medium |
Fix proposed to branch: master /review. opendev. org/c/openstack /neutron/ +/804218
Review: https:/