Bug 2001894
| Summary: | ImageTransfer phase changes to finished_success before the transfer finish and locks released | ||
|---|---|---|---|
| Product: | [oVirt] ovirt-engine | Reporter: | Jean-Louis Dupond <jean-louis> |
| Component: | BLL.Storage | Assignee: | Eyal Shenitzky <eshenitz> |
| Status: | CLOSED DUPLICATE | QA Contact: | Avihai <aefrat> |
| Severity: | high | Docs Contact: | |
| Priority: | high | ||
| Version: | 4.4.8.4 | CC: | bugs, nsoffer, pbar |
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | If docs needed, set a value | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2021-10-04 06:54:34 UTC | Type: | Bug |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | Storage | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
|
Description
Jean-Louis Dupond
2021-09-07 11:53:01 UTC
The documentation text flag should only be set after 'doc text' field is provided. Please provide the documentation text and set the flag to '?' again. Changing priority/severity to hight, this breaks backup functionality. (In reply to Jean-Louis Dupond from comment #0) > We have some redundant updates to FINISHED_SUCCESS in the code: > 1) > https://github.com/oVirt/ovirt-engine/blob/master/backend/manager/modules/ > bll/src/main/java/org/ovirt/engine/core/bll/storage/disk/image/ > TransferDiskImageCommand.java#L825 This is wrong. The FINISHED_* states should be set only after the command completed. They should not be part of the state machine. > I think this one gets called directly after FINALIZING_SUCCESS. > > 2) > https://github.com/oVirt/ovirt-engine/blob/master/backend/manager/modules/ > bll/src/main/java/org/ovirt/engine/core/bll/storage/disk/image/ > TransferDiskImageCommand.java#L1418 > > This one is called AFTER the lock is removed and everything is finished. > Guess this is the only one we should keep? Yes, but even this is wrong, it should set the phase *after* calling endSuccessfuly(). These issues were hidden when we deleted the transfer quickly after completion. Now that we keep the transfer for a while, clients waiting correctly for completion are broken. Pavel, is the root cause for this bug is the same as bug 1923178 ? (In reply to Eyal Shenitzky from comment #4) > Pavel, is the root cause for this bug is the same as bug 1923178 ? Yes, after looking at it I see the root case is the same as bug 1923178. It's just another interesting flow in which we fail on being unable to lock the VM vs. being unable to lock the disk (as in bug 1923178). But the reason is the same: "imagetransfer.finalize_transfer()" got "FINISHED_SUCCESS" too soon, before the disk and VM locks were actually released. (In reply to Pavel Bar from comment #5) > (In reply to Eyal Shenitzky from comment #4) > > Pavel, is the root cause for this bug is the same as bug 1923178 ? > > Yes, after looking at it I see the root case is the same as bug 1923178. > It's just another interesting flow in which we fail on being unable to lock > the VM vs. being unable to lock the disk (as in bug 1923178). > But the reason is the same: "imagetransfer.finalize_transfer()" got > "FINISHED_SUCCESS" too soon, before the disk and VM locks were actually > released. Thanks. Closing as duplication of bug 1923178 *** This bug has been marked as a duplicate of bug 1923178 *** |