Current Series Release Notes¶

18.0.0-15¶

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.

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.

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 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.

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)