Current Series Release Notes¶

18.0.0-34¶

Introduced an ORM-based API data mapping path that bypasses the data_model layer for API responses, mapping directly from database models to API models which significantly improves performance. The Quotas API controller and related types have been realigned to support new alternative processing path.

There is now a new denylist_vip_networks option making it possible to forbid some networks to be used as VIP network. This is useful if a deployment has a shared internal network for public IPs, to avoid wasting public IPv4 IPs.

Amphora image architecture now defaults to the architecture of the system it is built on instead of amd64.

Python 3.10 support has been dropped. The minimum version of Python now supported is Python 3.11.

Existing amphorae with certificates missing the SKI and AKI extensions will need certificate rotation (handled by octavia-housekeeping) or failover to obtain new compliant certificates.

Octavia now requires Taskflow >= 6.2.0 to support masking sensitive information from Taskflow logging.

The [DEFAULT] octavia_plugins option has been removed. This option has been unused.

Fixed QoS policy validation to use the user’s request context when checking if a QoS policy exists. Previously, the validation used service credentials instead of the user’s context, which could allow a user to assign a QoS policy belonging to another tenant to their load balancer.

Fixed a HAProxy configuration injection vulnerability via the redirect_url and redirect_prefix fields on L7 policies. The rfc3986 URL validator encodes control characters before validation, so newlines and spaces passed structural checks but were stored raw and written directly into the HAProxy configuration. The URL validator now rejects URLs containing control characters (U+0000-U+001F, U+007F-U+009F) and spaces before passing them to rfc3986. Existing invalid values in the database are detected at config generation time and cleared.

Fixed a HAProxy configuration injection vulnerability via the tls_ciphers field on listeners and pools. The field was not validated for control characters, allowing an attacker to inject arbitrary HAProxy configuration directives by embedding newlines in the cipher string. The API now rejects cipher strings containing characters outside the set allowed by OpenSSL (alphanumeric, -, +, !, :, @, =, _, .). Existing invalid values in the database are detected at config generation time and replaced with the configured defaults.

Fixes an issue where amphora image builds based on Ubuntu were impossible on ARM64 architecture. LP#2161068

Fixed a bug where an API call to create a Load Balancer could return a HTTP 500 Internal Server Error instead of a HTTP 400 Bad Request when it could not get the subnet.

Fixed amphora certificate generation when the issuing CA’s Subject Key Identifier (SKI) was not derived using SHA-1. The amphora certificate’s Authority Key Identifier (AKI) is now copied from the CA certificate’s SKI, with public-key derivation retained as a fallback for CAs without an SKI. This restores compatibility with CAs generated by cert-manager 1.20 and other issuers using a different SKI derivation algorithm.

Fixed an issue where amphora certificates generated by the local certificate generator were missing the Subject Key Identifier (SKI) and Authority Key Identifier (AKI) X.509 extensions. This caused TLS handshake failures when using Python 3.13+ or OpenSSL with strict X.509 verification enabled, as these environments now enforce RFC 5280 compliance by default.

Fixed HAProxy config generation when both cpu-map (multi vCPU amphora) and external-check (PING health monitor) are enabled. A missing newline in the Jinja2 template caused external-check to be appended to the cpu-map line, resulting in a fatal HAProxy configuration error.

Improving assignment of network interfaces in the amphora image to the correct namespace on reboot by ignoring alternative names and relying on the brief output of ip instead of transforming it in the pipe output.

Fixed an issue in plugin.sh for Devstack where unstack.sh would fail if the o-hm0 network wasn’t set up

Fixed a crash in octavia-worker under Python 3.14. Python 3.14 changed the default multiprocessing start method from fork to forkserver on Linux. The forkserver method requires pickling all arguments passed to child processes, which fails for oslo_config.ConfigOpts due to an unpicklable lambda inside _ConfigFileOpt.__init__. cotyledon.ServiceManager is now created with an explicit fork context to preserve the previous behaviour. (see https://bugs.launchpad.net/octavia/+bug/2156391)

Fixed the octavia-health-manager, octavia-driver-agent and amphora-agent daemons under Python 3.14. Python 3.14 changed the default multiprocessing start method from fork to forkserver on Linux. With forkserver the child processes no longer inherit the parsed configuration from the parent process and fell back to the default SQLite database instead of the configured one. These daemons now spawn their child processes with an explicit fork start method, like it was done before Python 3.14. (see https://bugs.launchpad.net/octavia/+bug/2156391)

Taskflow’s persistence driver now uses [database].max_retries configuration option for database connections.

Fixed continuous ZooKeeper session churn in ZookeeperTaskFlowDriver where a new KazooClient was created and immediately closed on every _extend_jobs() cycle (~every 8 seconds), causing kazoo.exceptions.ConnectionLoss errors in the Octavia worker log during load balancer operations (bug #2144800).