Bug 1306690
| Summary: | "StaleDataError: UPDATE statement on table 'floatingips' expected to update 1 row(s); 0 were matched" on removing instance | ||
|---|---|---|---|
| Product: | Red Hat OpenStack | Reporter: | Vadim Rutkovsky <vrutkovs> |
| Component: | openstack-neutron | Assignee: | Ihar Hrachyshka <ihrachys> |
| Status: | CLOSED ERRATA | QA Contact: | Toni Freger <tfreger> |
| Severity: | unspecified | Docs Contact: | |
| Priority: | medium | ||
| Version: | 7.0 (Kilo) | CC: | amuller, chrisw, ihrachys, nyechiel, srevivo |
| Target Milestone: | async | Keywords: | ZStream |
| Target Release: | 7.0 (Kilo) | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| Whiteboard: | |||
| Fixed In Version: | openstack-neutron-2015.1.4-12.el7ost | Doc Type: | Bug Fix |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2017-02-15 13:50:20 UTC | Type: | Bug |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
|
Description
Vadim Rutkovsky
2016-02-11 15:21:46 UTC
Any idea about this one? The upstream bug expired, it's not clear if this was fixed in OSP8+ and if so is there a patch that we can backport? Assaf, I spent some time comparing Kilo and Liberty code (since the upstream reporter claimed Liberty is fixed for him). Nothing that would stand out, expect maybe a set of retry decorators applied to base api entry points, starting from https://review.openstack.org/#/c/191540/ That said, it does not seem that StaleDataError is handled by the decorators, though I may miss something since I am not that fluent with oslo.db code. We probably want to backport those anyway since they drastically enhances API stability for deadlocks. Now, in upstream Liberty we also switched to another mysql driver (pymysql), and that could also contribute to the issue disappearing for the reporter when Liberty code is used. We definitely cannot change the driver in OSP7. Should I go and backport retry fixes? (In reply to Ihar Hrachyshka from comment #2) > Assaf, I spent some time comparing Kilo and Liberty code (since the upstream > reporter claimed Liberty is fixed for him). Nothing that would stand out, > expect maybe a set of retry decorators applied to base api entry points, > starting from https://review.openstack.org/#/c/191540/ That said, it does > not seem that StaleDataError is handled by the decorators, though I may miss > something since I am not that fluent with oslo.db code. > > We probably want to backport those anyway since they drastically enhances > API stability for deadlocks. > > Now, in upstream Liberty we also switched to another mysql driver (pymysql), > and that could also contribute to the issue disappearing for the reporter > when Liberty code is used. We definitely cannot change the driver in OSP7. > > Should I go and backport retry fixes? The retry decorators have come up in multiple contexts, I think that the answer is yes, we want them in OSP 7 as well. I think the fix is: https://review.openstack.org/#/c/192063/ and we backported it into the latest package. Steps to reproduce for the bug are not clear, as is often the case with race conditions. You can try to repeat creating and deleting instances (with floating IPs) while also deleting the floating IPs in parallel. From automation perspective, maybe it's just a matter of regression and stability tests using tempest. The code is verified on latest OSP7 - openstack-neutron-2015.1.4-12.el7ost.noarch Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://rhn.redhat.com/errata/RHBA-2017-0277.html |