Comment 25 for bug 1836252

This was seen in systems that were experiencing critical CPU alarms after an unlock.
An operation in neutron (enabling dhcp for a network) that should only take a few seconds at most, was exceeding the wait_until_true timeout of 60 seconds, so it stops that and dhcp is not functional for that network. This can be recovered by removing/readding the dhcp server to the dhcp agent.
I expect that this can be mitigated by addressing the root cause of the excessive platform cpu usage during an unlock.