[Bug 2150285] [NEW] Neutron 2026.1 with mod_wsgi packaging skips ML2 segment range initialization, causing tenant network creation failures

[Myles Penner]

Public bug reported:

In Ubuntu Resolute, the neutron-api package deploys the Neutron API
using Apache mod_wsgi. With Neutron 2026.1 / OpenStack Gazpacho, this
can prevent ML2 default network segment ranges from being initialized,
causing tenant network creation to fail with NoNetworkAvailable.

Ubuntu packaging currently installs neutron-api as an Apache/mod_wsgi
application:

 - debian/control: neutron-api depends on apache2 | httpd and libapache2-mod-wsgi-py3
 - debian/neutron-api.conf: uses WSGIDaemonProcess and WSGIScriptAlias
 - debian/neutron-api.wsgi: imports from neutron.wsgi.api import application

However, Neutron’s ML2 network segment range initialization now gates
initialization on the uWSGI worker ID:

if wsgi_utils.get_api_worker_id() != wsgi_utils.FIRST_WORKER_ID:
    return
wsgi_utils.get_api_worker_id() imports the uwsgi module and calls uwsgi.worker_id(). Under Apache mod_wsgi, the uwsgi module is not available, so this function returns None.

As a result:

None != 1

and initialize_network_segment_range_support() returns without
initializing the default network segment ranges.

In ML2/OVN deployments this leaves the allocation state for tenant
network segment types, such as Geneve, unpopulated. Tenant network
creation then fails with NoNetworkAvailable.


Impact
Fresh or upgraded Ubuntu/Sunbeam deployments using the packaged Apache/mod_wsgi neutron-api can bring up the API successfully but fail functional tenant network creation.

This is not just a CI issue. It affects a normal tenant workflow:

openstack network create private
or equivalent tenant network creation through the Neutron API.


Expected Result
Ubuntu’s packaged neutron-api deployment should initialize ML2 default network segment ranges and allow tenant networks to be created.


Actual Result
Default network segment ranges are not initialized under Apache mod_wsgi, and tenant network creation fails with NoNetworkAvailable.


Root Cause
Neutron 2026.1 assumes uWSGI runtime metadata in the ML2 segment range initialization path. Ubuntu’s package intentionally deploys neutron-api via Apache mod_wsgi, where import uwsgi fails and get_api_worker_id() returns None.

The relevant code is:

# neutron/common/wsgi_utils.py
def get_api_worker_id() -> int | None:
    try:
        import uwsgi
        return uwsgi.worker_id()
    except (ImportError, ModuleNotFoundError):
        return None
# neutron/plugins/ml2/managers.py
def initialize_network_segment_range_support(self, start_time):
    if wsgi_utils.get_api_worker_id() != wsgi_utils.FIRST_WORKER_ID:
        return


Proposed Fix
Allow non-uWSGI loaders to run segment range initialization while preserving existing uWSGI behavior:

worker_id = wsgi_utils.get_api_worker_id()
if worker_id is not None and worker_id != wsgi_utils.FIRST_WORKER_ID:
    return

This keeps the existing behavior for uWSGI:
 - worker 1 initializes
 - workers other than 1 skip
and fixes Apache/mod_wsgi:
 - missing worker ID no longer causes required initialization to be skipped

** Affects: neutron (Ubuntu)
     Importance: Undecided
         Status: New

-- 
You received this bug notification because you are a member of Ubuntu
OpenStack, which is subscribed to neutron in Ubuntu.
https://bugs.launchpad.net/bugs/2150285

Title:
  Neutron 2026.1 with mod_wsgi packaging skips ML2 segment range
  initialization, causing tenant network creation failures

Status in neutron package in Ubuntu:
  New

Bug description:
  In Ubuntu Resolute, the neutron-api package deploys the Neutron API
  using Apache mod_wsgi. With Neutron 2026.1 / OpenStack Gazpacho, this
  can prevent ML2 default network segment ranges from being initialized,
  causing tenant network creation to fail with NoNetworkAvailable.

  Ubuntu packaging currently installs neutron-api as an Apache/mod_wsgi
  application:

   - debian/control: neutron-api depends on apache2 | httpd and libapache2-mod-wsgi-py3
   - debian/neutron-api.conf: uses WSGIDaemonProcess and WSGIScriptAlias
   - debian/neutron-api.wsgi: imports from neutron.wsgi.api import application

  However, Neutron’s ML2 network segment range initialization now gates
  initialization on the uWSGI worker ID:

  if wsgi_utils.get_api_worker_id() != wsgi_utils.FIRST_WORKER_ID:
      return
  wsgi_utils.get_api_worker_id() imports the uwsgi module and calls uwsgi.worker_id(). Under Apache mod_wsgi, the uwsgi module is not available, so this function returns None.

  As a result:

  None != 1

  and initialize_network_segment_range_support() returns without
  initializing the default network segment ranges.

  In ML2/OVN deployments this leaves the allocation state for tenant
  network segment types, such as Geneve, unpopulated. Tenant network
  creation then fails with NoNetworkAvailable.

  
  Impact
  Fresh or upgraded Ubuntu/Sunbeam deployments using the packaged Apache/mod_wsgi neutron-api can bring up the API successfully but fail functional tenant network creation.

  This is not just a CI issue. It affects a normal tenant workflow:

  openstack network create private
  or equivalent tenant network creation through the Neutron API.

  
  Expected Result
  Ubuntu’s packaged neutron-api deployment should initialize ML2 default network segment ranges and allow tenant networks to be created.

  
  Actual Result
  Default network segment ranges are not initialized under Apache mod_wsgi, and tenant network creation fails with NoNetworkAvailable.

  
  Root Cause
  Neutron 2026.1 assumes uWSGI runtime metadata in the ML2 segment range initialization path. Ubuntu’s package intentionally deploys neutron-api via Apache mod_wsgi, where import uwsgi fails and get_api_worker_id() returns None.

  The relevant code is:

  # neutron/common/wsgi_utils.py
  def get_api_worker_id() -> int | None:
      try:
          import uwsgi
          return uwsgi.worker_id()
      except (ImportError, ModuleNotFoundError):
          return None
  # neutron/plugins/ml2/managers.py
  def initialize_network_segment_range_support(self, start_time):
      if wsgi_utils.get_api_worker_id() != wsgi_utils.FIRST_WORKER_ID:
          return

  
  Proposed Fix
  Allow non-uWSGI loaders to run segment range initialization while preserving existing uWSGI behavior:

  worker_id = wsgi_utils.get_api_worker_id()
  if worker_id is not None and worker_id != wsgi_utils.FIRST_WORKER_ID:
      return

  This keeps the existing behavior for uWSGI:
   - worker 1 initializes
   - workers other than 1 skip
  and fixes Apache/mod_wsgi:
   - missing worker ID no longer causes required initialization to be skipped

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