b5f5f3def3
previously we calculated the "load" of a chassis across the highest priority of each of the chassis. This can lead to suboptimal results in the following situation: * you have gateway chassis: hv1, hv2, hv3 * you have routers: * g1: with priority 3 on hv1, priority 2 on hv2, priority 1 on hv3 * g2: with priority 3 on hv1, priority 2 on hv2, priority 1 on hv3 * g3: with priority 3 on hv3, priority 2 on hv2, priority 1 on hv1 * g4: with priority 3 on hv3, priority 2 on hv2, priority 1 on hv1 When now creating a new router the previous algorythm would have placed prio 3 of it either on hv1 or hv3 since their count of highest priorities (2 of prio 3) is lower than the count of the higest priority of hv2 (4 of prio 2). So it might have looked like: * g5: with priority 3 on hv3, priority 2 on hv1, priority 1 on hv3 (This case has been implemented as `test_least_loaded_chassis_per_priority2`). However this is actually a undesired result. In OVN the gateway chassis with the highest priority actually hosts the router and processes all of its external traffic. This means it is highly important that the highest priority is well balanced. To do this now we no longer blindly use the count of routers of the highest priority per chassis, but we only count the routers of the priority we are currently searching a chassis for. This ensures that in the above case we would have picked hv2 for priority 3, since it has not actually active router running. The algorithm implemented now is based upon the assumption, that amount of priorities scheduled per router is equal over all routers. This means it will perform suboptimally if some phyiscal network is available on 5 gateway chassis, while another one is only available on 2. (It is however unclear if the previous implementation would have been better there). In this commit we also adopt the testcases in test_l3_ovn_scheduler to match to this assumption. Previously the distribution data used for testing had been unrelasitic as it mostly scheduled one gateway chassis for each router. It also fixes the previously broken priority calculation in the testcase, that would just assign prio 0 to all gateways. Partial-Bug: #2023993 Change-Id: If2afcd546a1da9964704bcebbfa39d8348e14fe8
OpenStack Neutron
Neutron is an OpenStack project to provide "network connectivity as a service" between interface devices (e.g., vNICs) managed by other OpenStack services (e.g., Nova).
To learn more about neutron:
- Documentation: https://docs.openstack.org/neutron/latest/
- Features: https://specs.openstack.org/openstack/neutron-specs
- Defects: https://launchpad.net/neutron
- Release notes: https://docs.openstack.org/releasenotes/neutron/index.html
- Source: https://opendev.org/openstack/neutron
If you would like to contribute to Neutron, please read the file CONTRIBUTING.rst or see the Neutron contributor guide:
https://docs.openstack.org/neutron/latest/contributor/contributing.html
Get in touch via email. Use [Neutron] in your subject.