Activity log for bug #1795212

Date Who What changed Old value New value Message
2018-09-30 08:46:46 Kailun Qin bug added bug
2018-09-30 08:46:57 Kailun Qin neutron: assignee Kailun Qin (kailun.qin)
2018-10-01 13:54:23 Nate Johnston tags rfe
2018-10-01 13:58:53 Nate Johnston tags rfe l3-ipam-dhcp rfe
2018-10-01 18:53:41 Nate Johnston neutron: importance Undecided Wishlist
2018-10-10 15:57:25 OpenStack Infra neutron: status New In Progress
2018-10-10 17:15:41 Brian Haley bug added subscriber Brian Haley
2018-10-19 20:07:33 OpenStack Infra neutron: assignee Kailun Qin (kailun.qin) Brian Haley (brian-haley)
2018-10-20 02:41:04 OpenStack Infra neutron: assignee Brian Haley (brian-haley) Kailun Qin (kailun.qin)
2018-10-26 01:14:45 Kailun Qin neutron: status In Progress New
2018-10-26 01:22:32 OpenStack Infra neutron: status New In Progress
2018-10-26 08:55:11 Kailun Qin description Network rescheduling would be triggered when neutron server is discovering that agents are down. At the same time, some bare metal and node management systems will reboot those same nodes at the same time. When those two actions happen together, it will result in the server sending RPC notifications to agents that just get rebooted which will lead to stale RPC messages when the DHCP agents return to service. These messages were sent to the agent before the node was rebooted but were not processed by the agent because it was shutdown at the time. The negative effects brought by this case would be: when an agent has received a stale network create/end notification, it will be triggered to start servicing a network even though the server may have already had that network assigned to a different agent. Since the agent does not periodically audit the list of networks that it is servicing it could potentially continue servicing a network that was not assigned to it forever. Similarly, it is possible that a stale delete message is processed thus causing the agent to stop servicing a network that it was actually supposed to service. Network rescheduling would be triggered when neutron server is discovering that agents are down. At the same time, some bare metal and node management systems will reboot those same nodes. When those two actions happen together, it will result in the server sending RPC notifications to agents that just get rebooted which will lead to stale RPC messages when the DHCP agents return to service. These messages were sent to the agent before the node was rebooted but were not processed by the agent because it was shutdown at that time. The negative effects brought by this case would be: when an agent has received a stale network create/end notification, it will be triggered to start servicing a network even though the server may have already had that network assigned to a different agent. Since the agent does not periodically audit the list of networks that it is servicing it could potentially continue servicing a network that was not assigned to it forever. Similarly, it is possible that a stale delete message is processed thus causing the agent to stop servicing a network that it was actually supposed to service.
2018-11-07 20:56:02 Miguel Lavalle tags l3-ipam-dhcp rfe l3-ipam-dhcp rfe-confirmed
2018-12-21 01:34:17 Miguel Lavalle tags l3-ipam-dhcp rfe-confirmed l3-ipam-dhcp rfe-triaged
2019-01-03 21:40:28 Miguel Lavalle tags l3-ipam-dhcp rfe-triaged l3-ipam-dhcp rfe-confirmed
2019-06-13 22:01:47 Miguel Lavalle tags l3-ipam-dhcp rfe-confirmed rfe-postponed