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

Fri May 29 22:58:59 UTC 2026

Debdiff for patch to neutron as well as unit test and autopkgtest
improvement.

** Description changed:

+ [Impact]
+ This release sports mostly bug-fixes and we would like to make sure all of our users have access to these improvements.
+ 
+ The update contains the following package updates:
+ - neutron 2:28.0.0-0ubuntu1.1
+ 
+ [Test Case]
+ This upload extends the existing neutron-api autopkgtest (debian/tests/neutron-api) so it directly exercises the mod_wsgi fix. The test deploys the Neutron API under Apache mod_wsgi (the package's default, WSGIDaemonProcess processes=4) with the geneve type driver and the network_segment_range service plugin enabled, then asserts the behaviour that was broken:
+ 
+ a default network segment range is seeded exactly once;
+ the OVN hash ring has one node per mod_wsgi worker, all sharing a single start time (created_at);
+ that start time advances across an apache2 restart.
+ On the package currently in the release pocket these assertions fail (segment ranges are never seeded and the hash-ring workers race into deleting each other's rows); on the fixed package they pass. A verifier therefore only needs to run the neutron-api autopkgtest against -proposed and confirm it passes, e.g.:
+ 
+ autopkgtest --test-name=neutron-api neutron --apt-pocket=proposed
+ 
+ -- lxd autopkgtest/ubuntu/<series>/amd64
+ 
+ The following SRU process was followed:
+ https://documentation.ubuntu.com/sru/en/latest/reference/exception-OpenStack-Updates
+ 
+ In order to avoid regression of existing consumers, the OpenStack team will run their continuous integration test against the packages that are in -proposed.  A successful run of all available tests will be required before the
+ proposed packages can be let into -updates.
+ 
+ The OpenStack team will be in charge of attaching the output summary of
+ the executed tests. The OpenStack team members will not mark
+ ‘verification-done’ until this has happened.
+ 
+ [Regression Potential]
+ In order to mitigate the regression potential, the results of the aforementioned tests are attached to this bug.
+ 
+ The neutron change (LP: #2150285) is gated behind the mod_wsgi Python
+ module being importable, so uWSGI, CLI, and unit-test code paths are
+ unchanged; regression exposure is limited to Apache mod_wsgi API
+ deployments. The added behaviour (per-worker ID election and a shared,
+ restart-advancing start time) was verified end-to-end on resolute under
+ mod_wsgi: default segment ranges are seeded once, and OVN hash-ring
+ workers share one start time that advances across an apache2 restart.
+ 
+ [Discussion]
+ neutron 2:28.0.0-0ubuntu1.1 carries a single downstream-only fix (LP: #2150285) that keeps the Neutron API operational under Apache mod_wsgi for one more cycle. Upstream supports only uWSGI, which exposes a worker ordinal and a shared server start time; under mod_wsgi these are absent, so default network segment ranges were never seeded and OVN hash-ring workers raced into deleting each other's rows. The patch supplies both via lock/sentinel files under /var/lib/neutron/lock and relaxes the ML2 first-worker guard as an idempotent safety net. It is marked Forwarded: not-needed and is intended to be dropped once the API is switched to uWSGI-only.
+ 
+ 
+ --------------------------------------------------------------------------------
+ Original Bug Report Below
+ --------------------------------------------------------------------------------
+ 
  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
+  - 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
+     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
+     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
- 
+     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
+     return

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

** Patch added: "lp2150285_28.0.0-0ubuntu1.1.debdiff"
   https://bugs.launchpad.net/ubuntu/+source/neutron/+bug/2150285/+attachment/5974431/+files/lp2150285_28.0.0-0ubuntu1.1.debdiff

-- 
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:
  [Impact]
  This release sports mostly bug-fixes and we would like to make sure all of our users have access to these improvements.

  The update contains the following package updates:
  - neutron 2:28.0.0-0ubuntu1.1

  [Test Case]
  This upload extends the existing neutron-api autopkgtest (debian/tests/neutron-api) so it directly exercises the mod_wsgi fix. The test deploys the Neutron API under Apache mod_wsgi (the package's default, WSGIDaemonProcess processes=4) with the geneve type driver and the network_segment_range service plugin enabled, then asserts the behaviour that was broken:

  a default network segment range is seeded exactly once;
  the OVN hash ring has one node per mod_wsgi worker, all sharing a single start time (created_at);
  that start time advances across an apache2 restart.
  On the package currently in the release pocket these assertions fail (segment ranges are never seeded and the hash-ring workers race into deleting each other's rows); on the fixed package they pass. A verifier therefore only needs to run the neutron-api autopkgtest against -proposed and confirm it passes, e.g.:

  autopkgtest --test-name=neutron-api neutron --apt-pocket=proposed

  -- lxd autopkgtest/ubuntu/<series>/amd64

  The following SRU process was followed:
  https://documentation.ubuntu.com/sru/en/latest/reference/exception-OpenStack-Updates

  In order to avoid regression of existing consumers, the OpenStack team will run their continuous integration test against the packages that are in -proposed.  A successful run of all available tests will be required before the
  proposed packages can be let into -updates.

  The OpenStack team will be in charge of attaching the output summary
  of the executed tests. The OpenStack team members will not mark
  ‘verification-done’ until this has happened.

  [Regression Potential]
  In order to mitigate the regression potential, the results of the aforementioned tests are attached to this bug.

  The neutron change (LP: #2150285) is gated behind the mod_wsgi Python
  module being importable, so uWSGI, CLI, and unit-test code paths are
  unchanged; regression exposure is limited to Apache mod_wsgi API
  deployments. The added behaviour (per-worker ID election and a shared,
  restart-advancing start time) was verified end-to-end on resolute
  under mod_wsgi: default segment ranges are seeded once, and OVN hash-
  ring workers share one start time that advances across an apache2
  restart.

  [Discussion]
  neutron 2:28.0.0-0ubuntu1.1 carries a single downstream-only fix (LP: #2150285) that keeps the Neutron API operational under Apache mod_wsgi for one more cycle. Upstream supports only uWSGI, which exposes a worker ordinal and a shared server start time; under mod_wsgi these are absent, so default network segment ranges were never seeded and OVN hash-ring workers raced into deleting each other's rows. The patch supplies both via lock/sentinel files under /var/lib/neutron/lock and relaxes the ML2 first-worker guard as an idempotent safety net. It is marked Forwarded: not-needed and is intended to be dropped once the API is switched to uWSGI-only.

  --------------------------------------------------------------------------------
  Original Bug Report Below
  --------------------------------------------------------------------------------

  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