Bug 1567509
Summary: | [Infra] Error writing to data store- node was deleted by another transaction | ||
---|---|---|---|
Product: | Red Hat OpenStack | Reporter: | Sai Sindhur Malleni <smalleni> |
Component: | opendaylight | Assignee: | Michael Vorburger <vorburger> |
Status: | CLOSED WONTFIX | QA Contact: | Noam Manos <nmanos> |
Severity: | medium | Docs Contact: | |
Priority: | medium | ||
Version: | 13.0 (Queens) | CC: | aadam, mkolesni, smalleni |
Target Milestone: | --- | Keywords: | Triaged, ZStream |
Target Release: | 14.0 (Rocky) | ||
Hardware: | Unspecified | ||
OS: | Unspecified | ||
Whiteboard: | Infra | ||
Fixed In Version: | Doc Type: | If docs needed, set a value | |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2019-03-06 16:15:14 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
Sai Sindhur Malleni
2018-04-14 14:29:39 UTC
*** Bug 1567508 has been marked as a duplicate of this bug. *** > make sure to clean the logs from the stack trace since this exception is expected where was this determined, and how will that actually make the VM pingable? Let's have a closer look in https://jira.opendaylight.org/browse/NETVIRT-1215 ... Sai, as far as I can tell from looking at the netvrit code upstream (which I'm not an expert on), there should already be retries in the code, so this is indeed a "false" error log.. I've just raised two changes which should suppress this, but it won't actually "fix" anything - so if "we see that some VMs remain unpingable", that's actually another real issue probably (do you see any other errors in the log when this happens?) - would you like to open a new BZ about that for someone else, so that we can close this one when we'll have the logging cleaned up? AFAIK when an optimistic lock fails it is an expected behavior since that's how optimistic locking works. Let me know if that's not the case.. > when an optimistic lock fails it is an expected behavior
> since that's how optimistic locking works.
> Let me know if that's not the case.
Well, no, it's not the case. It's really a little bit more complicated:
IFF we have code for handling optimistic lock failures in ODL e.g. via retries, then we shold not show ERROR logs. This is often done wrong in code I see and review.
But if we do not, then such ERROR logs do indicate the writes failed. So to just blindly demand "to clean the logs from the stack trace since this exception is expected" is not the correct solution. Instead, we must make sure we "handle" this in the respective code (e.g. with retries triggered by correct exception handling) - see NETVIRT-1215.
As per depreciation notice [1], closing this bug. Please reopen if relevant for RHOSP13, as this is the only version shipping ODL. [1] https://access.redhat.com/documentation/en-us/red_hat_openstack_platform/14/html-single/release_notes/index#deprecated_functionality As per depreciation notice [1], closing this bug. Please reopen if relevant for RHOSP13, as this is the only version shipping ODL. [1] https://access.redhat.com/documentation/en-us/red_hat_openstack_platform/14/html-single/release_notes/index#deprecated_functionality |