[Bug 2156391] Re: Octavia fails on deploy Debian 13

Guillaume Boutry 2156391 at bugs.launchpad.net
Mon Sep 21 06:39:05 UTC 2026 

** Also affects: octavia (Ubuntu)
   Importance: Undecided
       Status: New

** Also affects: octavia (Ubuntu Resolute)
   Importance: Undecided
       Status: New

** Also affects: octavia (Ubuntu Stonking)
   Importance: Undecided
       Status: New

** Changed in: octavia (Ubuntu Stonking)
       Status: New => Invalid

** 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]
+ 
+ 1. Install the proposed package on a system running Python 3.14.
+ 
+ 2. Create a temporary Octavia configuration:
+ 
+    mkdir -p /tmp/octavia-sru
+    cat >/tmp/octavia-sru/octavia.conf <<EOF
+    [DEFAULT]
+    log_dir = /tmp/octavia-sru
+    transport_url = rabbit://invalid:invalid@127.0.0.1:5672/
+ 
+    [database]
+    connection = sqlite:////tmp/octavia-sru/configured.sqlite
+    EOF
+ 
+ 3. Start the health manager while tracing file access:
+ 
+    strace -ff -o /tmp/octavia-sru/trace -e trace=file \
+        octavia-health-manager \
+        --config-file /tmp/octavia-sru/octavia.conf
+ 
+    Allow the service to start for approximately 10 seconds, then stop
+ it.
+ 
+ 4. Inspect the trace files:
+ 
+    grep -hE 'configured.sqlite|octavia.sqlite|sqlite' \
+        /tmp/octavia-sru/trace*
+ 
+ 5. With the unfixed package, the child processes attempt to access the default
+    Octavia SQLite database rather than the configured database.
+ 
+ 6. With the proposed package, the child processes use:
+ 
+    /tmp/octavia-sru/configured.sqlite
+ 
+    and do not access the default octavia.sqlite database.
+ 
+ 7. Start octavia-driver-agent with the same configuration and verify that its
+    listener processes start without multiprocessing errors.
+ 
+ 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.
+ 
+ [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

** Summary changed:

- Octavia fails on deploy Debian 13
+ [SRU] octavia: Fix multiprocessing configuration inheritance with Python 3.14

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

Title:
  [SRU] octavia: Fix multiprocessing configuration inheritance with
  Python 3.14

Status in octavia:
  Fix Released
Status in octavia package in Ubuntu:
  Invalid
Status in octavia source package in Resolute:
  New
Status in octavia source package in Stonking:
  Invalid

Bug description:
  [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]

  1. Install the proposed package on a system running Python 3.14.

  2. Create a temporary Octavia configuration:

     mkdir -p /tmp/octavia-sru
     cat >/tmp/octavia-sru/octavia.conf <<EOF
     [DEFAULT]
     log_dir = /tmp/octavia-sru
     transport_url = rabbit://invalid:invalid@127.0.0.1:5672/

     [database]
     connection = sqlite:////tmp/octavia-sru/configured.sqlite
     EOF

  3. Start the health manager while tracing file access:

     strace -ff -o /tmp/octavia-sru/trace -e trace=file \
         octavia-health-manager \
         --config-file /tmp/octavia-sru/octavia.conf

     Allow the service to start for approximately 10 seconds, then stop
  it.

  4. Inspect the trace files:

     grep -hE 'configured.sqlite|octavia.sqlite|sqlite' \
         /tmp/octavia-sru/trace*

  5. With the unfixed package, the child processes attempt to access the default
     Octavia SQLite database rather than the configured database.

  6. With the proposed package, the child processes use:

     /tmp/octavia-sru/configured.sqlite

     and do not access the default octavia.sqlite database.

  7. Start octavia-driver-agent with the same configuration and verify that its
     listener processes start without multiprocessing errors.

  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.

  [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

To manage notifications about this bug go to:
https://bugs.launchpad.net/octavia/+bug/2156391/+subscriptions

More information about the Ubuntu-openstack-bugs mailing list