So looking at the code here, _get_new_operating_statuses is completely wrong and inefficient.
There should be no reason calculating the operating status to send back to the API should need any historical information. Operating status is the "observed" point-in-time status of the load balancer and it's child objects.
The OVN provider should be calculating the current status based on the current status of those objects in OVN.
Looking at the code here, you already have all of the required status information from OVN from the "ovn_lb.external_ids.items()" call. You just need to apply the business logic you want to use (in this case, since you are using the Octavia tempest suite, it will need to match the amphora driver).
The first step is evaluate the members:
Collect the status of your member objects from OVN
If they are administratively down, set it to OFFLINE
If they have no health monitor, set it to NO_MONITOR
If OVN supports "weight 0" draining (I don't think it does), set it to DRAINING
If the member is failing health checks, or otherwise not functioning, set it to ERROR
Step two, calculate the pool status:
If it is administratively down, set it to OFFLINE
If the pool has a capacity limit or any other OVN proprietary out-of-service, set it to ERROR
If all of the members are in ERROR (calculated above), set it to ERROR
If one or more of the members are ERROR, but not all, set it to DEGRADED
Otherwise, the pool is ONLINE
Step three, calculate the health monitor status:
If the health monitor is administratively down, set it to OFFLINE
If the health monitor is broken in some way, set it to ERROR
Otherwise the health monitor is ONLINE
Step four, calculate the listener status:
If the listener is administratively down, set it to OFFLINE
If the listener is out of capacity (i.e. at it's connection limit setting), set it to DEGRADED
If one or more associated pools are DEGRADED, set the listener to DEGRADED
If one or more of the pools is in ERROR, set the listener to ERROR
Otherwise, the listener is ONLINE
Step four, calculate the load balancer status:
If the load balancer is administratively down, set it to OFFLINE
If one or more of the listeners is DEGRADED, set it to DEGRADED
If one or more of the listeners is ERROR, set it to ERROR
Otherwise, the load balancer is ONLINE
That should provide you with everything you need to make the update_loadbalancer_status() call.
So looking at the code here, _get_new_ operating_ statuses is completely wrong and inefficient.
There should be no reason calculating the operating status to send back to the API should need any historical information. Operating status is the "observed" point-in-time status of the load balancer and it's child objects.
The OVN provider should be calculating the current status based on the current status of those objects in OVN.
Looking at the code here, you already have all of the required status information from OVN from the "ovn_lb. external_ ids.items( )" call. You just need to apply the business logic you want to use (in this case, since you are using the Octavia tempest suite, it will need to match the amphora driver).
The first step is evaluate the members:
Collect the status of your member objects from OVN
If they are administratively down, set it to OFFLINE
If they have no health monitor, set it to NO_MONITOR
If OVN supports "weight 0" draining (I don't think it does), set it to DRAINING
If the member is failing health checks, or otherwise not functioning, set it to ERROR
Step two, calculate the pool status:
If it is administratively down, set it to OFFLINE
If the pool has a capacity limit or any other OVN proprietary out-of-service, set it to ERROR
If all of the members are in ERROR (calculated above), set it to ERROR
If one or more of the members are ERROR, but not all, set it to DEGRADED
Otherwise, the pool is ONLINE
Step three, calculate the health monitor status:
If the health monitor is administratively down, set it to OFFLINE
If the health monitor is broken in some way, set it to ERROR
Otherwise the health monitor is ONLINE
Step four, calculate the listener status:
If the listener is administratively down, set it to OFFLINE
If the listener is out of capacity (i.e. at it's connection limit setting), set it to DEGRADED
If one or more associated pools are DEGRADED, set the listener to DEGRADED
If one or more of the pools is in ERROR, set the listener to ERROR
Otherwise, the listener is ONLINE
Step four, calculate the load balancer status:
If the load balancer is administratively down, set it to OFFLINE
If one or more of the listeners is DEGRADED, set it to DEGRADED
If one or more of the listeners is ERROR, set it to ERROR
Otherwise, the load balancer is ONLINE
That should provide you with everything you need to make the update_ loadbalancer_ status( ) call.