Current Series Release Notes¶
11.0.0-16¶
New Features¶
The Octavia OVN DB sync plugin for
neutron-ovn-db-sync-utilnow registers--octavia-config-fileto 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
ONLINEwhen they finished and rewrote every stored member status from the row as read when they started; on OVN versions that create theService_Monitoralreadyofflinethe agent could report a down memberERRORbefore that, so it stayedONLINE. An operation now reports only the operating status it can justify,OFFLINEfor an admin-down member andNO_MONITORwithout 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_mappingsentry is per address, and only members of other pools were checked before removing it, so the remaining member lost itsService_Monitorand 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_Monitoris created is now reported asERROR. OVN versions that create the row alreadyoffline(OVN commitde8dc3f9a8) never update it for such a backend, and only updates were handled, so the member stayedONLINEforever.
Health check events are matched to the exact member. The member was previously looked up by substring, so an event for
10.0.0.1could be applied to10.0.0.10, or an event for port9to any member of the same address whose ID contains a9.
When the
Service_Monitorof an enabled member is deleted, the member is now set toERRORinstead ofOFFLINE.OFFLINEremoves 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 withopenstack 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
ERRORinstead ofONLINE. 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 readingONLINEwhile 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.