← Back to team overview

yahoo-eng-team team mailing list archive

[Bug 2015275] Re: Trunk port update_subport_bindings RPC call not processed by RPC workers

 

Reviewed:  https://review.opendev.org/c/openstack/neutron/+/916112
Committed: https://opendev.org/openstack/neutron/commit/ffcaeda32adf32388c322cfc6f7a8933ef94d2a9
Submitter: "Zuul (22348)"
Branch:    master

commit ffcaeda32adf32388c322cfc6f7a8933ef94d2a9
Author: Sebastian Lohff <sebastian.lohff@xxxxxxx>
Date:   Mon Apr 15 16:14:50 2024 +0200

    Start trunk plugin RPC via service framework
    
    Instead of each individual driver setting up the RPC server (and setting
    the _rpc_backend attribute on the TrunkPlugin) we now check in the
    TrunkPlugin if any driver requires the RPC backend to be started.
    Additionally, we only start it when this is requested by Neutron via
    start_rpc_listeners(). This is required when running neutron-server and
    neutron-rpc-server separately to run RPC only in neutron-rpc-server.
    
    As we still need the notifiers of ServerSideRpcBackend to be
    created/started, we separate TrunkSkeleton (which is the RPC server
    implementation) and ServerSideRpcBackend (which is essentially only a
    notifier). In case RPC is required by a driver, we always start the
    notifier, but the RPC server only when requested via
    start_rpc_listeners().
    
    Change-Id: I2c6362b3320e534a6e65bd7701b5ac2feca42a49
    Closes-Bug: #2015275
    Closes-Bug: #2062009


** Changed in: neutron
       Status: In Progress => Fix Released

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
https://bugs.launchpad.net/bugs/2015275

Title:
  Trunk port update_subport_bindings RPC call not processed by RPC
  workers

Status in neutron:
  Fix Released

Bug description:
  OpenStack Yoga deployed with OpenStack ansible shows
  update_subport_bindings RPC call is only handled by the parent
  neutron-server process and never by the RPC worker threads.
  Additionally if Neutron is configured to utilize uWSGI these threads
  also process the update_subport_bindings RPC call, this seems counter-
  intuitive.

  To reproduce configure neutron to use uWSGI and create multiple trunk
  ports at the same time.  The parent RPC process can still handle
  update_subport_bindings RPC calls but none of the workers can.
  Multiple ports should be created to give a better chance for the uWSGI
  threads to handle the call or to show only the parent process handles
  the calls.  Enable debugging to more easily see the process handling
  the request.

  Expectation is that RPC workers could also process
  update_subport_bindings and that uWSGI threads wouldn't

  My understanding of the Neutron software baseline is very weak but my
  understanding for why this happens is as follows:

  Parent neutron-server thread and uWSGI threads handle the trunk RPC
  calls because they both instantiate the NeutronManger which loads
  trunk/plugin.  Trunk/plugin then registers the rpc backend via
  service/trunk/drivers/base.

  Why the RPC workers don't respond I am less sure.  Perhaps because
  they dont implement start_rpc_listeners for the trunk plugin but I'm
  unsure.  Is this a design choice?

  Running OpenStack Yoga cluster with 3 neutron-server nodes on RHEL8
  provisioned with OpenStack ansible.  Configured to used LinuxBridges
  as the backend.

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/2015275/+subscriptions



References