10191fd817
This is an approximate partial fix to #1828375. update_trunk_status and update_subport_bindings rpc messages are processed concurrently and possibly out of order on the server side. Therefore they may race with each other. The status update race combined with 1) the versioning feature of sqlalchemy used in the standardattributes table and 2) the less than serializable isolation level of some DB backends (like MySQL InnoDB) does raise StaleDataErrors and by that leaves some trunk subports in DOWN status. This change retries the trunk status update (to BUILD) blindly when StaleDataError was caught. In my local testbed this practically fixes #1828375. However theoretically the retry may cover up other real errors (when the cause of the StaleDataError was a different status not just a different revision count). To the best of my understanding a proper fix would entail guaranteeing the in order processing of the above rpc messages - which likely won't ever happen. I'm not sure at all if this change is worth merging - let me know what you think. Conflicts: neutron/services/trunk/rpc/server.py neutron/tests/unit/services/trunk/rpc/test_server.py Change-Id: Ie581809f24f9547b55a87423dac7db933862d66a Partial-Bug: #1828375 (cherry picked from commit |
||
|---|---|---|
| .. | ||
| auto_allocate | ||
| externaldns | ||
| flavors | ||
| l3_router | ||
| logapi | ||
| loki | ||
| metering | ||
| network_ip_availability | ||
| qos | ||
| rbac | ||
| revisions | ||
| segments | ||
| tag | ||
| timestamp | ||
| trunk | ||
| __init__.py | ||
| provider_configuration.py | ||
| service_base.py | ||