If an agent tries to report_state to the neutron-server and it fails
because of a timeout (raising oslo_messaging.MessagingTimeout), then
there is an exponential back-off effect, which causes the
seemingly-simple report_state RPC call to take 60 seconds, then 120,
then 240 and so on. This can happen if all the controllers are
restarted simultaneously a number of time, as the bug report describes.
Since the feature was intended for heavy RPC calls (like get_routers())
and not for light calls such as report_state, it's safe to reduce the
timeout to a constant 60 seconds interval.
Reviewed: https:/ /review. openstack. org/347708 /git.openstack. org/cgit/ openstack/ neutron/ commit/ ?id=bb989be99db 84a2789abe2849c 786a075e3f5ab7
Committed: https:/
Submitter: Jenkins
Branch: master
commit bb989be99db84a2 789abe2849c786a 075e3f5ab7
Author: John Schwarz <email address hidden>
Date: Wed Jul 27 12:09:30 2016 +0300
Don't use exponential back-off for report_state
If an agent tries to report_state to the neutron-server and it fails MessagingTimeou t), then simple report_state RPC call to take 60 seconds, then 120,
because of a timeout (raising oslo_messaging.
there is an exponential back-off effect, which causes the
seemingly-
then 240 and so on. This can happen if all the controllers are
restarted simultaneously a number of time, as the bug report describes.
Since the feature was intended for heavy RPC calls (like get_routers())
and not for light calls such as report_state, it's safe to reduce the
timeout to a constant 60 seconds interval.
Closes-Bug: #1606827 59bb1a8ee933b8b 2ce1e64b695
Change-Id: I15aeea9f8265b8