** Description changed: [Impact] Python 3.14 changed the default multiprocessing start method on Linux from fork to forkserver. Octavia child processes no longer inherit the parsed configuration from the parent process. As a result, octavia-health-manager can connect to the default SQLite database instead of the database configured in octavia.conf. The same issue affects octavia-driver-agent and amphora-agent. - [Test Case] + [Test Plan] - 1. Install the proposed package on a system running Python 3.14. + On a Resolute system, install the release version of + octavia-health-manager: - 2. Create a temporary Octavia configuration: + sudo apt update + sudo apt install octavia-health-manager + apt policy octavia-health-manager + python3 --version - mkdir -p /tmp/octavia-sru - cat >/tmp/octavia-sru/octavia.conf <<EOF - [DEFAULT] - log_dir = /tmp/octavia-sru - transport_url = rabbit://invalid:[email protected]:5672/ + Stop the service: - [database] - connection = sqlite:////tmp/octavia-sru/configured.sqlite - EOF + sudo systemctl stop octavia-health-manager - 3. Start the health manager while tracing file access: + Configure a persistent SQLite database and shorten the initial health-check + delay: - strace -ff -o /tmp/octavia-sru/trace -e trace=file \ - octavia-health-manager \ - --config-file /tmp/octavia-sru/octavia.conf + sudo cp /etc/octavia/octavia.conf \ + /etc/octavia/octavia.conf.sru-backup - Allow the service to start for approximately 10 seconds, then stop - it. + sudo tee /etc/octavia/octavia.conf >/dev/null <<'EOF' + [database] + connection = sqlite:////var/lib/octavia/sru-test.sqlite - 4. Inspect the trace files: + [health_manager] + heartbeat_timeout = 1 + health_check_interval = 5 + EOF - grep -hE 'configured.sqlite|octavia.sqlite|sqlite' \ - /tmp/octavia-sru/trace* + Initialize the configured database: - 5. With the unfixed package, the child processes attempt to access the default - Octavia SQLite database rather than the configured database. + sudo -u octavia octavia-db-manage \ + --config-file /etc/octavia/octavia.conf upgrade head - 6. With the proposed package, the child processes use: + Confirm that the database contains the Octavia schema: - /tmp/octavia-sru/configured.sqlite + sudo -u octavia sqlite3 /var/lib/octavia/sru-test.sqlite \ + '.tables' | grep amphora - and do not access the default octavia.sqlite database. + Start the service and wait for at least one health-check cycle: - 7. Start octavia-driver-agent with the same configuration and verify that its - listener processes start without multiprocessing errors. + sudo systemctl start octavia-health-manager + sleep 15 - 8. If an amphora image is rebuilt with the proposed package, start - amphora-agent and verify that the agent starts without multiprocessing - errors and uses its configured settings. + Confirm the running multiprocessing implementation: + + systemctl status octavia-health-manager --no-pager + ps -eo pid,ppid,args --forest | + grep -E '[o]ctavia-health-manager|[f]orkserver' + + With the release package, the child processes are created through + multiprocessing.forkserver. They do not inherit the parsed configuration and + use the default in-memory SQLite database. The health-check child therefore + reports: + + sqlite3.OperationalError: no such table: amphora + + Verify the failure with: + + sudo journalctl -u octavia-health-manager \ + --since '-1 minute' --no-pager | + grep -E 'sqlite3.OperationalError|no such table: amphora' + + Install the proposed package and restart the service: + + sudo apt install octavia-health-manager=<PROPOSED_VERSION> + sudo systemctl restart octavia-health-manager + sleep 15 + + Confirm the installed version: + + apt policy octavia-health-manager + + Confirm that forkserver children are no longer present: + + ps -eo pid,ppid,args --forest | + grep -E '[o]ctavia-health-manager|[f]orkserver' + + Confirm that the service remains active: + + systemctl is-active octavia-health-manager + + Confirm that no missing-table errors occurred after the restart: + + sudo journalctl -u octavia-health-manager \ + --since '-1 minute' --no-pager | + grep -E 'sqlite3.OperationalError|no such table: amphora' + + The final grep must produce no output. The service must remain active. This + demonstrates that the health-check child inherited the configured database + connection and successfully used the initialized database. [Regression Potential] The change affects process creation in octavia-health-manager, octavia-driver-agent, and amphora-agent. A regression could prevent child processes from starting, affect process shutdown, or cause daemon-specific configuration to be unavailable in child processes. The patch changes only the multiprocessing context used to create child processes, explicitly selecting fork on Linux. Existing daemon startup, shutdown, and unit tests should be run. Amphora-agent validation requires an amphora image rebuilt with the proposed package. [Other Info] This is reverting to pre-3.14 default multiprocessing context. This has been fixed across the openstack ecosystem for the hibiscus release (stonking) - --- Original description OpenStack 2026.1 or 2026.2 Debian 13 Python 3.14 CI test: https://review.opendev.org/c/openstack/openstack-ansible-os_octavia/+/992498 Details: https://zuul.opendev.org/t/openstack/build/b4e551ae920e4099a68b67dde31a8c9b/log/logs/host/octavia-worker.service.journal-17-27-02.log.txt https://zuul.opendev.org/t/openstack/build/b4e551ae920e4099a68b67dde31a8c9b/log/logs/host/octavia-health-manager.service.journal-17-27-02.log.txt
-- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/2156391 Title: [SRU] octavia: Fix multiprocessing configuration inheritance with Python 3.14 To manage notifications about this bug go to: https://bugs.launchpad.net/octavia/+bug/2156391/+subscriptions -- ubuntu-bugs mailing list [email protected] https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
