yahoo-eng-team team mailing list archive

[John Bartelme <2015275@xxxxxxxxxxxxxxxxxx>]

Public bug reported:

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.

** Affects: neutron
     Importance: Undecided
         Status: New

-- 
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:
  New

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