neutron

Bug #1289066
Comment #2

Comment 2 for bug 1289066

Revision history for this message

OpenStack Infra (hudson-openstack) wrote on 2014-07-15: Fix merged to neutron (master)

Reviewed: https://review.openstack.org/78819
Committed: https://git.openstack.org/cgit/openstack/neutron/commit/?id=fe2ca9a75878a445a54ecfe4a97c79b696abf503
Submitter: Jenkins
Branch: master

commit fe2ca9a75878a445a54ecfe4a97c79b696abf503
Author: Carl Baldwin <email address hidden>
Date: Thu Mar 6 23:57:11 2014 +0000

L3 agent prefers RPC messages over full sync

When the L3 agent starts up and runs the sync task it doesn't process
any incoming RPC events until the sync task is complete.

    This change combines the work from _rpc_loop and _sync_routers_task in
    to a single loop called _process_routers_loop. This loop spawns
    threads that pull from a priority queue. The queue ensures that RPC
    messages are handled before _process_routers_loop. The latter is
    generally maintenance tasks triggered by the agent rather than user
    triggered tasks.

    Synchronization between RPC and sync routers loops is no longer
    necessary since they both feed in to a single queue. There were
    places where it was necessary to reorder some things to allow for the
    lack of synchronization. For example, it is necessary to list
    namespaces before fetching the full list of routers to ensure that it
    doesn't delete a new namespace that gets created after listing
    namespaces. The lack of the need for synchronization between loops is
    probably the main strength of this patch.

    With multiple worker threads, need to handle the case where an RPC
    message came in while a thread was working on a router. Another
    thread should not handle the same router that is already in progress.
    Adds a mechanism to signal to the working thread that an update came
    in for the router it is working on. The original thread will repeat
    processing the router when it is finished to get the update.
    Multiple rapid updates to the same router will be consolidated.
    Essentially, there is still synchronization of work for a given router
    but not between routers. Much better than before.

    blueprint l3-agent-responsiveness
    Closes-Bug: #1289066
    Change-Id: I39afe86c66f864d71adf865d7bd1c9db35511505

Reviewed:  https://review.openstack.org/78819
Committed: https://git.openstack.org/cgit/openstack/neutron/commit/?id=fe2ca9a75878a445a54ecfe4a97c79b696abf503
Submitter: Jenkins
Branch:    master

commit fe2ca9a75878a445a54ecfe4a97c79b696abf503
Author: Carl Baldwin <carl.baldwin@hp.com>
Date:   Thu Mar 6 23:57:11 2014 +0000

L3 agent prefers RPC messages over full sync
    
    When the L3 agent starts up and runs the sync task it doesn't process
    any incoming RPC events until the sync task is complete.
    
    This change combines the work from _rpc_loop and _sync_routers_task in
    to a single loop called _process_routers_loop.  This loop spawns
    threads that pull from a priority queue.  The queue ensures that RPC
    messages are handled before _process_routers_loop.  The latter is
    generally maintenance tasks triggered by the agent rather than user
    triggered tasks.
    
    Synchronization between RPC and sync routers loops is no longer
    necessary since they both feed in to a single queue.  There were
    places where it was necessary to reorder some things to allow for the
    lack of synchronization.  For example, it is necessary to list
    namespaces before fetching the full list of routers to ensure that it
    doesn't delete a new namespace that gets created after listing
    namespaces.  The lack of the need for synchronization between loops is
    probably the main strength of this patch.
    
    With multiple worker threads, need to handle the case where an RPC
    message came in while a thread was working on a router.  Another
    thread should not handle the same router that is already in progress.
    Adds a mechanism to signal to the working thread that an update came
    in for the router it is working on.  The original thread will repeat
    processing the router when it is finished to get the update.
    Multiple rapid updates to the same router will be consolidated.
    Essentially, there is still synchronization of work for a given router
    but not between routers.  Much better than before.
    
    blueprint l3-agent-responsiveness
    Closes-Bug: #1289066
    Change-Id: I39afe86c66f864d71adf865d7bd1c9db35511505