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.
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.