[RFE] Replace the timer based periodic resync task of DHCP agents with an event driven one

Bug #1780370 reported by Kailun Qin
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
neutron
Fix Released
Wishlist
Kailun Qin

Bug Description

The DHCP agent will resync its state with Neutron to recover from any transient notification or RPC errors. Currently, the periodic resync task waits on a timer to determine whether a re-sync is necessary. The interval between attempts by default is 5 seconds. This may cause a potentially long delay before an agent gets new work via an agent_updated RPC call.

The idea of this RFE is to change the timer based periodic resync task into a event driven one. We could force the agent to act on the resync request immediately therefore decreasing how much time is needed before DHCP services are available.

Tags: rfe-approved
Kailun Qin (kailun.qin)
Changed in neutron:
assignee: nobody → Kailun Qin (kailun.qin)
tags: added: rfe
Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Fix proposed to neutron (master)

Fix proposed to branch: master
Review: https://review.openstack.org/580548

Changed in neutron:
status: New → In Progress
Revision history for this message
Brian Haley (brian-haley) wrote :

Let's discuss at next neutron drivers meeting, Friday 7/20 at 10am EST is the next one, on #openstack-meeting.

tags: added: rfe-triaged
removed: rfe
Revision history for this message
YAMAMOTO Takashi (yamamoto) wrote :

this sounds reasonable.
i'm not sure if this needs to be handled as a RFE though.

Miguel Lavalle (minsel)
Changed in neutron:
importance: Undecided → Wishlist
Revision history for this message
Miguel Lavalle (minsel) wrote :

This RFE is approved. There was concern in the drivers team about how to handle events if they are too frequent. Decided to discuss those details in https://review.openstack.org/580548

tags: added: rfe-approved
removed: rfe-triaged
Revision history for this message
Kailun Qin (kailun.qin) wrote :

Addressed the concern about how to handle events if they are too frequent by introducing a resync_throttle to guarantee the minimum event interval. Can we have this RFE to move forward? Thanks a lot.

Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Fix merged to neutron (master)

Reviewed: https://review.openstack.org/580548
Committed: https://git.openstack.org/cgit/openstack/neutron/commit/?id=1d98f0a7d43bc45b66260053bde76d992fd613b8
Submitter: Zuul
Branch: master

commit 1d98f0a7d43bc45b66260053bde76d992fd613b8
Author: Kailun Qin <email address hidden>
Date: Fri Jul 6 20:20:08 2018 +0800

    Event driven periodic resync task for DHCP agents

    The DHCP agent will resync its state with Neutron to recover from any
    transient notification or RPC errors. Currently, the periodic resync
    task waits on a timer to determine whether a re-sync is necessary. The
    interval between attempts by default is 5 seconds and can be longer
    thru config. This may cause a potentially long delay before an agent
    gets new work via an agent_updated RPC call.

    The idea of this RFE is to change the timer based periodic resync task
    into an event driven one. It also proposes a new DHCP agent config
    option "resync_throttle" to ensure the minimum interval taken between
    resync state events to avoid too frequent resyncing. In this way, we
    could force the agent to act on the resync request immediately therefore
    decreasing how much time is needed before DHCP services are available.

    Co-authored-by: Allain Legacy <email address hidden>

    Closes-Bug: #1780370
    Change-Id: Ie9d758ba5f750a38dc19ea5ce8b2c6b414f9ef80

Changed in neutron:
status: In Progress → Fix Released
Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Fix included in openstack/neutron 14.0.0.0b1

This issue was fixed in the openstack/neutron 14.0.0.0b1 development milestone.

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.