Created attachment 1379860 [details] engine log Description of problem: After Cancel Upload/Download disk was successful via UI I would expect that it should not give ERROR's in Engine log or UI event log but to give a message that cancel transfer was completed successfully & in engine log give an INFO message. I expect ERRORs in log/UI when cancel download/upload operation fails. Version-Release number of selected component (if applicable): 4.2.1-0.2.el7 How reproducible: 100% Steps to Reproduce: 1.Start upload/download disk image 2.Cancle upload/download operation Actual results: Although cancel is successful we throw an error message in the UI/engine log. 2018-01-11 09:22:21,759+02 ERROR [org.ovirt.engine.core.bll.storage.disk.image.TransferDiskImageCommand] (EE-ManagedThreadFactory-engineScheduled-Thread-52) [0f51677a-7ec1-4bba-905f-cb16eeb2ae56] Transfer failed. Upload disk 'Fedora-Workstation-netinst-x86_64-26-1.5.iso' (id '00000000-0000-0000-0000-000000000000') 2018-01-11 09:22:22,776+02 INFO [org.ovirt.engine.core.bll.storage.disk.image.ImageTransferUpdater] (EE-ManagedThreadFactory-engineScheduled-Thread-79) [0f51677a-7ec1-4bba-905f-cb16eeb2ae56] Updating image transfer 996c1428-a97f-4cdf-a088-136b2513bcfd (image 917556a9-041b-424a-8823-453082cb2ef7) phase to Finished Failure (message: 'Sent 11.171875MB') 2018-01-11 09:22:22,837+02 ERROR [org.ovirt.engine.core.bll.storage.disk.image.TransferDiskImageCommand] (EE-ManagedThreadFactory-engineScheduled-Thread-79) [0f51677a-7ec1-4bba-905f-cb16eeb2ae56] Failed to transfer disk '00000000-0000-0000-0000-000000000000' (command id '996c1428-a97f-4cdf-a088-136b2513bcfd') Expected results: If cancel is successful do not throw an error message in the UI/engine log. Additional info:
This behaviour is actually by design, cancelling a transfer operation initiates the failure flow (which clears the ImageTransfer). Thus, we output a failure log ("Failed to transfer disk..."), to indicate that the transfer indeed failed. So, the log could be either ERROR or WARN. @Yaniv/Allon - any take on that? Should we change the log to WARN?
(In reply to Daniel Erez from comment #1) > This behaviour is actually by design, cancelling a transfer operation > initiates the failure flow (which clears the ImageTransfer). Thus, we output > a failure log ("Failed to transfer disk..."), to indicate that the transfer > indeed failed. So, the log could be either ERROR or WARN. > > @Yaniv/Allon - any take on that? Should we change the log to WARN? To be on a user initiated cancellation is should be INFO. Allon, thoughts?
(In reply to Yaniv Lavi from comment #2) > (In reply to Daniel Erez from comment #1) > > This behaviour is actually by design, cancelling a transfer operation > > initiates the failure flow (which clears the ImageTransfer). Thus, we output > > a failure log ("Failed to transfer disk..."), to indicate that the transfer > > indeed failed. So, the log could be either ERROR or WARN. > > > > @Yaniv/Allon - any take on that? Should we change the log to WARN? Correction: > To me, on a user initiated cancellation, it should be INFO level. Allon, thoughts?
(In reply to Yaniv Lavi from comment #3) > (In reply to Yaniv Lavi from comment #2) > > (In reply to Daniel Erez from comment #1) > > > This behaviour is actually by design, cancelling a transfer operation > > > initiates the failure flow (which clears the ImageTransfer). Thus, we output > > > a failure log ("Failed to transfer disk..."), to indicate that the transfer > > > indeed failed. So, the log could be either ERROR or WARN. > > > > > > @Yaniv/Allon - any take on that? Should we change the log to WARN? > Correction: > > To me, on a user initiated cancellation, it should be INFO level. Allon, thoughts? This flow is actually mutual to both flows (i.e. cancellation initiated by a user or due to an internal failure).
We should distinguish between a transfer failure (which is an ERROR) and a user proactively canceling the transfer (INFO) - at least in the engine. I'm fine with them being treated the same in the lower level components if this simplifies things.
Daniel, how complicated will it be to add a boolean of some sort distinguishing in the failure flows whether the cleanup is due to an error or a user initiated one and change the log accordingly?
(In reply to Tal Nisan from comment #6) > Daniel, how complicated will it be to add a boolean of some sort > distinguishing in the failure flows whether the cleanup is due to an error > or a user initiated one and change the log accordingly? It's probably more difficult than that. When I looked into it last time, it required some refactoring in the command's state machine. I would keep it for re-evaluation in 4.3.
This bug has not been marked as blocker for oVirt 4.3.0. Since we are releasing it tomorrow, January 29th, this bug has been re-targeted to 4.3.1.
Verified on ovirt-engine 4.3.5.2-0.1.el7 Engine log showing image upload/download cancle as INFO not ERROR: 2019-07-02 10:51:03,335+03 INFO [org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector] (EE-ManagedThreadFactory-engineScheduled-Thread-6) [cb1c3b3f-6511-4c5f-b37f-272b0bd53e12] EVENT_ID: TRANSF ER_IMAGE_CANCELLED(1,033), Image Upload with disk upload was cancelled. 2019-07-02 10:56:21,479+03 INFO [org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector] (EE-ManagedThreadFactory-engineScheduled-Thread-13) [a45924a3-8d8b-4809-b578-aca945900c43] EVENT_ID: TRANSFER_IMAGE_CANCELLED(1,033), Image Download with disk floating_disk_test was cancelled. Same was seen in UI. Steps to Reproduce: 1.Start upload/download disk image 2.Cancle upload/download operation Cancel is successful and do not throw an error message in the UI/engine log.
This bugzilla is included in oVirt 4.3.5 release, published on July 30th 2019. Since the problem described in this bug report should be resolved in oVirt 4.3.5 release, it has been closed with a resolution of CURRENT RELEASE. If the solution does not work for you, please open a new bug report.