Current Series Release Notes

11.0.0-16

New Features

  • The Octavia OVN DB sync plugin for neutron-ovn-db-sync-util now registers --octavia-config-file to load Octavia configuration into an isolated oslo.config object. When the option is not provided, the plugin still falls back to /etc/octavia/octavia.conf.

Bug Fixes

  • A health check verdict is no longer overwritten by the operation that caused it. Creating or enabling a member, and creating a health monitor, reported the members ONLINE when they finished and rewrote every stored member status from the row as read when they started; on OVN versions that create the Service_Monitor already offline the agent could report a down member ERROR before that, so it stayed ONLINE. An operation now reports only the operating status it can justify, OFFLINE for an admin-down member and NO_MONITOR without a monitor, for the members it acted on, and merges the statuses into the row when the transaction commits. A new or re-enabled member of a monitored pool, and the members of a pool given a health monitor, keep their status in Octavia until the first verdict, as with the amphora driver, and so do the pool, listener and load balancer whose status depends on that verdict. A member whose monitor already has a status, one shared with another member of the same backend, has it replayed by the agent.

  • Disabling or deleting a member no longer removes the health check of another member of the same pool on the same address. The ip_port_mappings entry is per address, and only members of other pools were checked before removing it, so the remaining member lost its Service_Monitor and its status was no longer updated. Deleting a health monitor applies the same rule, and no longer keeps the entry for an administratively disabled member of another pool.

  • A member whose backend is already down when its Service_Monitor is created is now reported as ERROR. OVN versions that create the row already offline (OVN commit de8dc3f9a8) never update it for such a backend, and only updates were handled, so the member stayed ONLINE forever.

  • Health check events are matched to the exact member. The member was previously looked up by substring, so an event for 10.0.0.1 could be applied to 10.0.0.10, or an event for port 9 to any member of the same address whose ID contains a 9.

  • When the Service_Monitor of an enabled member is deleted, the member is now set to ERROR instead of OFFLINE. OFFLINE removes a member from the load balancer backends, which removed its monitor as well, so the member could never be reported back online and received no traffic until it was disabled and re-enabled. Members already stuck that way recover with openstack loadbalancer member set --enable.

  • Detaching from a router the network of a member no longer takes the load balancer off that router when its VIP is on another network still attached to it. The load balancer used to leave every switch of the router, its own VIP switch included, and stopped answering while its members read ONLINE. It now only leaves the switch of the detached network. Detaching one subnet of a network the router is still on through another subnet leaves every load balancer where it is.

  • A member that answers its health check but is not routed from the load balancer VIP is now reported as ERROR instead of ONLINE. The check probes a member from a port on the member’s own subnet, so a member subnet detached from the VIP’s router, or attached to another router, kept reading ONLINE while every request to the VIP timed out. Reachability is judged from the networks and static routes of the routers the load balancer is on, leaving out default routes since a router with an external gateway would otherwise reach every member, and from the switches of its VIP ports, and members are re-reported when a router interface is added or removed. The status stored in the Northbound database is still the health check’s.