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 Bugs, which is subscribed to 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 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/neutron/+bug/2150285/+subscriptions -- ubuntu-bugs mailing list [email protected] https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
