Bug 1523813 - Cannot deactivate Storage while there are running tasks on this Storage
Summary: Cannot deactivate Storage while there are running tasks on this Storage
Keywords:
Status: CLOSED DEFERRED
Alias: None
Product: ovirt-system-tests
Classification: Community
Component: General
Version: 2.0
Hardware: x86_64
OS: Linux
unspecified
medium
Target Milestone: ---
: ---
Assignee: grosenth
QA Contact: meital avital
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2017-12-08 19:26 UTC by Dafna Ron
Modified: 2023-09-18 00:13 UTC (History)
2 users (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2022-09-16 09:02:07 UTC
oVirt Team: External
Embargoed:
dron: planning_ack?
dron: devel_ack?
dron: testing_ack?


Attachments (Terms of Use)

Description Dafna Ron 2017-12-08 19:26:10 UTC
We had a failure on master basic suite for test 007_sd_reattach.deactivate_storage_domain.

The failure was that we failed to deactivate domain due to running tasks.

It does not seem to be related to the patch it was testing and I think that the test itself needs to be modified to check there are no running tasks.

Possible solution suggested by ykaul is to wrap it with try, except sdk4.Error and let it sit within the testlib.assert_true_within_short() loop.


Link and headline of suspected patches: Not related to error

Link to Job: http://jenkins.ovirt.org/job/ovirt-master_change-queue-tester/4319/

Link to all logs: http://jenkins.ovirt.org/job/ovirt-master_change-queue-tester/4319/artifact/

(Relevant) error snippet from the log: 

<error>


2017-12-06 20:13:23,166-05 WARN  [org.ovirt.engine.core.bll.storage.domain.DeactivateStorageDomainWithOvfUpdateCommand] (default task-7) [d82880e8-1d40-4a3b-a1ba-3362f2f130a0] Validation of action 'DeactivateStorageDomainWithOvfUpdate' fa
iled for user admin@internal-authz. Reasons: VAR__TYPE__STORAGE__DOMAIN,VAR__ACTION__DEACTIVATE,ERROR_CANNOT_DEACTIVATE_DOMAIN_WITH_TASKS
2017-12-06 20:13:23,167-05 INFO  [org.ovirt.engine.core.bll.storage.domain.DeactivateStorageDomainWithOvfUpdateCommand] (default task-7) [d82880e8-1d40-4a3b-a1ba-3362f2f130a0] Lock freed to object 'EngineLock:{exclusiveLocks='[ea2fd992-8a
a4-44fe-aa43-e96754a975ba=STORAGE]', sharedLocks='[5e0a0183-0e25-4f43-b5b0-0cfb5510248e=POOL]'}'
2017-12-06 20:13:23,172-05 DEBUG [org.ovirt.engine.core.common.di.interceptor.DebugLoggingInterceptor] (default task-7) [d82880e8-1d40-4a3b-a1ba-3362f2f130a0] method: runAction, params: [DeactivateStorageDomainWithOvfUpdate, DeactivateSto
rageDomainWithOvfUpdateParameters:{commandId='630c28e1-41ab-43db-9755-a2bb870dbcb3', user='null', commandType='Unknown'}], timeElapsed: 65ms
2017-12-06 20:13:23,176-05 ERROR [org.ovirt.engine.api.restapi.resource.AbstractBackendResource] (default task-7) [] Operation Failed: [Cannot deactivate Storage while there are running tasks on this Storage.
-Please wait until tasks will finish and try again.]


<error>

Comment 1 RHV bug bot 2017-12-31 13:44:40 UTC
I'm not sure this should go under the ovirt-system-tests product, we can probably remove this product from oVirt since we use JIRA to report issues on OST.

If this is a real bug, then it should be on the relevant oVirt component, vdsm or engine?

Comment 3 Tal Nisan 2018-05-14 09:22:31 UTC
The behavior is right, you shouldn't be able to deactivate while there are running tasks so something in the flow is probably not right.
This suggestion makes sense to me:
"Possible solution suggested by ykaul is to wrap it with try, except sdk4.Error and let it sit within the testlib.assert_true_within_short() loop."

Comment 4 Sandro Bonazzola 2019-06-21 09:11:50 UTC
Is this still an issue?

Comment 5 Michal Skrivanek 2022-09-16 09:02:07 UTC
OST is not using bugzilla for tracking for a while, closing outstanding open bugs.
If you wish to follow up on this issue please do so at https://github.com/oVirt/ovirt-system-tests

Comment 6 Red Hat Bugzilla 2023-09-18 00:13:00 UTC
The needinfo request[s] on this closed bug have been removed as they have been unresolved for 120 days


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