Red Hat Bugzilla – Bug 1028765
[RFE] Display canDoAction messages from commands executed during the flow after the initial canDoAction checks succeeded
Last modified: 2016-02-10 14:06:33 EST
Created attachment 822090 [details]
engine.log and screenshot
Description of problem:
When live storage migration fails because another operation was managed to take a lock on the disk, user don't get any error about the failure.
Happened to me when during LSM, I tried to attach the disk snapshot to another VM with REST (as part of the new backup-API feature)
Version-Release number of selected component (if applicable):
Steps to Reproduce:
On a block/file pool with 2 SDs:
1. create 2 VMs with disk and run them
2. live migrate one of the VMs disk to the second SD
3. during the LSM operation (right after it began), attach the disk snapshot (the one that is simultaneously migrating) to the other running vm using REST
The disk attachment operation succeeds and LSM fails.
LSM is failing with a CanDoAction:
2013-11-10 15:56:12,613 WARN [org.ovirt.engine.core.bll.lsm.LiveMigrateVmDisksCommand] (ajp-/127.0.0.1:8702-4) [47722e08] CanDoAction of action LiveMigrateVmDisks failed. Reasons:VAR__ACTION__MOVE,VAR__TYPE__VM_D
User don't get any notification about the LSM failure
Engine should report about the failure on UI.
Additional info: engine.log and screenshot
The main issue is that after the command execution has started, CDA messages from called commands during the execution flow (including LSM) won't be displayed as the command is already being executed.
The issue specifically in that bug was resolved by the given patch as the taken locks were removed from LiveMigrateDiskCommand (for other CDA messages there will be an audit log).
Therefore i'm changing this to a RFE of displaying CDA messages from commands executed after initial CDA checks were done.
is this done or not? the only associated patch to this bug is merged?
Not done, the provided patch solves the bug - but doesn't implplement the RFE related to it.
Bug is closed due to a missing use case. Also I'd avoid auto-logging messages to the audit log which has no audit-log-type since this bypass the audit-log messages flooding mechanism.