Bug 1127121 - [RFE] Consider pending jobs for storage allocation checks
Summary: [RFE] Consider pending jobs for storage allocation checks
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: ovirt-engine
Classification: oVirt
Component: RFEs
Version: ---
Hardware: Unspecified
OS: Unspecified
unspecified
medium vote
Target Milestone: ---
: ---
Assignee: bugs@ovirt.org
QA Contact: Raz Tamir
URL:
Whiteboard:
: 1127830 (view as bug list)
Depends On: 1127830
Blocks:
TreeView+ depends on / blocked
 
Reported: 2014-08-06 08:22 UTC by Vered Volansky
Modified: 2016-12-06 12:32 UTC (History)
8 users (show)

Fixed In Version:
Doc Type: Enhancement
Doc Text:
Clone Of:
Environment:
Last Closed: 2016-12-06 12:32:00 UTC
oVirt Team: Storage
ylavi: ovirt-future?
ylavi: planning_ack?
ylavi: devel_ack?
ylavi: testing_ack?


Attachments (Terms of Use)

Description Vered Volansky 2014-08-06 08:22:55 UTC
Description of problem:
Storage jobs are checking for free space on CDA - verifying the current state.
Jobs sent one after the other check the already allocated space, so if there's a pending or ongoing (approved) job, the space it's about to consume is not taken into consideration, causing it to ultimately fail (though CDA passed).

Space checks should take into consideration pendin-jobs future-space-consumption.

Steps to Reproduce:
1. NFS DC
2. Storage with 30G
3. Pre-allocated 30G disk
4. Immediately after that allocate several 1-3G preallocated disks on the same storage.

Actual results:
Small disks are allocated, and finally (few minutes) vdsm notifies failure on the big disk and roles back nicely.

Expected results:
Small disks creation should CDA fail.

Additional info:
Opened as a result of bz1053742 verification, comment#6 and discussion with Ori regarding the steps taken and expected results.
Relevant log from there:
2014-08-04 18:25:44,613 ERROR [org.ovirt.engine.core.vdsbroker.vdsbroker.HSMGetAllTasksStatusesVDSCommand] (DefaultQuartzScheduler_Worker-75) Failed in HSMGetAllTasksStatusesVDS method
2014-08-04 18:25:44,614 INFO  [org.ovirt.engine.core.bll.tasks.SPMAsyncTask] (DefaultQuartzScheduler_Worker-75) SPMAsyncTask::PollTask: Polling task ec8bfc50-7f59-4a09-b059-dfef5d3f1427 (Parent Command AddDisk, Parameters Type org.ovirt.engine.core.common.asynctasks.AsyncTaskParameters) returned status finished, result 'cleanSuccess'.
2014-08-04 18:25:44,629 ERROR [org.ovirt.engine.core.bll.tasks.SPMAsyncTask] (DefaultQuartzScheduler_Worker-75) BaseAsyncTask::LogEndTaskFailure: Task ec8bfc50-7f59-4a09-b059-dfef5d3f1427 (Parent Command AddDisk, Parameters Type org.ovirt.engine.core.common.asynctasks.AsyncTaskParameters) ended with failure:
-- Result: cleanSuccess
-- Message: VDSGenericException: VDSErrorException: Failed to HSMGetAllTasksStatusesVDS, error = Cannot zero out volume, code = 374,
-- Exception: VDSGenericException: VDSErrorException: Failed to HSMGetAllTasksStatusesVDS, error = Cannot zero out volume, code = 374
2014-08-04 18:25:44,646 INFO  [org.ovirt.engine.core.bll.tasks.CommandAsyncTask] (DefaultQuartzScheduler_Worker-75) CommandAsyncTask::EndActionIfNecessary: All tasks of command 5c5a7ac1-ff29-4389-9059-020c44f43aaa has ended -> executing endAction
2014-08-04 18:25:44,654 INFO  [org.ovirt.engine.core.bll.tasks.CommandAsyncTask] (DefaultQuartzScheduler_Worker-75) CommandAsyncTask::endAction: Ending action for 1 tasks (command ID: 5c5a7ac1-ff29-4389-9059-020c44f43aaa): calling endAction .
2014-08-04 18:25:44,662 INFO  [org.ovirt.engine.core.bll.tasks.CommandAsyncTask] (org.ovirt.thread.pool-8-thread-23) CommandAsyncTask::EndCommandAction [within thread] context: Attempting to endAction AddDisk, executionIndex: 0
2014-08-04 18:25:44,672 ERROR [org.ovirt.engine.core.bll.AddDiskCommand] (org.ovirt.thread.pool-8-thread-23) [421c4c60] Ending command with failure: org.ovirt.engine.core.bll.AddDiskCommand

Comment 1 Allon Mureinik 2014-08-08 16:55:51 UTC
*** Bug 1127830 has been marked as a duplicate of this bug. ***

Comment 2 Allon Mureinik 2015-04-19 15:37:23 UTC
Closing old bugs, as per Itamar's guidlines.
If you think this bug is worth fixing, please feel free to reopen.

Comment 4 Yaniv Lavi 2016-12-05 13:23:25 UTC
Should this be closed?

Comment 5 Allon Mureinik 2016-12-06 12:32:00 UTC
(In reply to Yaniv Dary from comment #4)
> Should this be closed?
Yeah, probably.
This will never be important enough to do, and frankly, with a number of abstraction layers these checks need to cross, I doubt this would even be useful if we do implement it.


Note You need to log in before you can comment on or make changes to this bug.