|Summary:||CoCo infrastructure should provide a timeout for each command to prevent entities to be locked forever.|
|Product:||[oVirt] ovirt-engine||Reporter:||Maor <mlipchuk>|
|Component:||Backend.Core||Assignee:||Ravi Nori <rnori>|
|Status:||CLOSED CURRENTRELEASE||QA Contact:||Petr Matyáš <pmatyas>|
|Version:||3.6.0||CC:||amureini, bugs, gklein, lsurette, masayag, oourfali, pstehlik, rbalakri, Rhev-m-bugs, rnori, yeylon, ykaul|
|Fixed In Version:||Doc Type:||Bug Fix|
Cause: Some commands executed by Command Coordinator may not finish and may run for ever. Consequence: The commands are running for ever. Fix: The commands should be marked as FAILED after a user configurable number of minutes. CoCoLifeInMinutes in VdcOptions table can be used to configure the time out for CoCo commands Result: The CoCo commands that are still running after CoCoLifeInMinutes will be marked as FAILED and failure logic is executed.
|Last Closed:||2016-03-11 07:21:06 UTC||Type:||Bug|
|oVirt Team:||Infra||RHEL 7.3 requirements from Atomic Host:|
Description Maor 2015-09-10 05:20:00 UTC
Description of problem: CoCo infrastructure should provide a timeout for each command to prevent entities to be locked forever. The behavior should be a bit similar to how it is being dome with asyncTasks. There should be a parameter in the base parameter command that should be initialized every time with the default timeout, so the user will also be able to override it for specific operations. Version-Release number of selected component (if applicable): How reproducible: Steps to Reproduce: 1. Failed delete operations might make the client (CoCo) poll every time to check if the entity still exists 2. 3. Actual results: The entity will be locked forever, since the delete will never happen Expected results: We should have a time out (or number of tries) that when this limit reached the entity will leave the lock state and present a failure event log Additional info:
Comment 1 Red Hat Bugzilla Rules Engine 2015-10-20 14:00:11 UTC
Fixed bug tickets must have version flags set prior to fixing them. Please set the correct version flags and move the bugs back to the previous status after this is corrected.
Comment 2 Red Hat Bugzilla Rules Engine 2015-10-20 14:00:11 UTC
Target release should be placed once a package build is known to fix a issue. Since this bug is not modified, the target version has been reset. Please use target milestone to plan a fix for a oVirt release.
Comment 3 Yaniv Lavi 2015-10-29 12:33:34 UTC
In oVirt testing is done on single release by default. Therefore I'm removing the 4.0 flag. If you think this bug must be tested in 4.0 as well, please re-add the flag. Please note we might not have testing resources to handle the 4.0 clone.
Comment 4 Petr Matyáš 2016-02-23 17:11:21 UTC
Verified on 3.6.3-3