Bug 802806

Summary: while importing VM from export domain, storage description should be editable (currently fails)
Product: [oVirt] vdsm Reporter: Dafna Ron <dron>
Component: GeneralAssignee: Allon Mureinik <amureini>
Status: CLOSED CURRENTRELEASE QA Contact: Kevin Alon Goldblatt <kgoldbla>
Severity: low Docs Contact:
Priority: low    
Version: ---CC: amureini, bazulay, bsettle, bugs, laravot, lpeer, mlipchuk, srevivo, tnisan, ykaul, ylavi
Target Milestone: ovirt-4.2.0Flags: rule-engine: ovirt-4.2+
sherold: Triaged+
Target Release: 4.20.0   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2017-12-20 11:41:33 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: Storage RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
logs none

Description Dafna Ron 2012-03-13 14:31:16 UTC
Created attachment 569693 [details]
logs

Description of problem:

in NFS storage, I imported vm's and then tried to rename the domain. 
since an update to the domain's metadata is required during rename (description is changed) user dialogue for edit domain will remain opened for several minutes until we get time out in vdsm for resource lock. 

1) this makes the user think that the gui is stuck and will most likely try to log in again and perform same action. we need to allow description changes to metadata or fail operation right away. 

2) I am opening an RFE to change the lock from whole domain to only metadata

Version-Release number of selected component (if applicable):

rhevm-backend-3.0.3_0001-3.el6.x86_64
vdsm-4.9-112.8.el6_2.x86_64

How reproducible:

100%

Steps to Reproduce:
1. import vm's from export domain 
2. try to change domain name in rhevm 
3.
  
Actual results:

user dialogue will remain open until we get timeout from vdsm on resource lock. 

Expected results:

we should be able to change description in metadata filed or fail operation sooner. 

Additional info: full logs attached 

vdsm log:

Thread-1249::ERROR::2012-03-13 11:49:15,523::task::868::TaskManager.Task::(_setError) Unexpected error
Traceback (most recent call last):
  File "/usr/share/vdsm/storage/task.py", line 876, in _run
    return fn(*args, **kargs)
  File "/usr/share/vdsm/storage/hsm.py", line 1278, in public_setStorageDomainDescription
    vars.task.getExclusiveLock(STORAGE, sdUUID)
  File "/usr/share/vdsm/storage/task.py", line 1311, in getExclusiveLock
    self.resOwner.acquire(namespace, resName, resourceManager.LockType.exclusive, timeout)
  File "/usr/share/vdsm/storage/resourceManager.py", line 686, in acquire
    raise se.ResourceTimeout()
ResourceTimeout: Resource timeout: ()
Thread-1249::DEBUG::2012-03-13 11:49:15,524::task::495::TaskManager.Task::(_debug) Task 9ed69ed2-e4b0-4eed-b49e-66a69b01d9e8: Task._run: 9ed69ed2-e4b0-4eed-b49e-66a69b01d9e8 ('470fcf1a-975b-42ec-a814-13f6f60a7378', 'nfs_change') {} faile
d - stopping task
Thread-1249::DEBUG::2012-03-13 11:49:15,524::task::495::TaskManager.Task::(_debug) Task 9ed69ed2-e4b0-4eed-b49e-66a69b01d9e8: stopping in state preparing (force False)
Thread-1249::DEBUG::2012-03-13 11:49:15,525::task::495::TaskManager.Task::(_debug) Task 9ed69ed2-e4b0-4eed-b49e-66a69b01d9e8: ref 1 aborting True
Thread-1249::INFO::2012-03-13 11:49:15,525::task::1171::TaskManager.Task::(prepare) aborting: Task is aborted: 'Resource timeout: ()' - code 100
Thread-1249::DEBUG::2012-03-13 11:49:15,525::task::495::TaskManager.Task::(_debug) Task 9ed69ed2-e4b0-4eed-b49e-66a69b01d9e8: Prepare: aborted: Resource timeout: ()
Thread-1249::DEBUG::2012-03-13 11:49:15,526::task::495::TaskManager.Task::(_debug) Task 9ed69ed2-e4b0-4eed-b49e-66a69b01d9e8: ref 0 aborting True
Thread-1249::DEBUG::2012-03-13 11:49:15,526::task::495::TaskManager.Task::(_debug) Task 9ed69ed2-e4b0-4eed-b49e-66a69b01d9e8: Task._doAbort: force False
Thread-1249::DEBUG::2012-03-13 11:49:15,526::resourceManager::824::ResourceManager.Owner::(cancelAll) Owner.cancelAll requests {}
Thread-1249::DEBUG::2012-03-13 11:49:15,527::task::495::TaskManager.Task::(_debug) Task 9ed69ed2-e4b0-4eed-b49e-66a69b01d9e8: moving from state preparing -> state aborting
Thread-1249::DEBUG::2012-03-13 11:49:15,527::task::495::TaskManager.Task::(_debug) Task 9ed69ed2-e4b0-4eed-b49e-66a69b01d9e8: _aborting: recover policy none
Thread-1249::DEBUG::2012-03-13 11:49:15,527::task::495::TaskManager.Task::(_debug) Task 9ed69ed2-e4b0-4eed-b49e-66a69b01d9e8: moving from state aborting -> state failed
Thread-1249::DEBUG::2012-03-13 11:49:15,528::resourceManager::789::ResourceManager.Owner::(releaseAll) Owner.releaseAll requests {} resources {}
Thread-1249::DEBUG::2012-03-13 11:49:15,528::resourceManager::824::ResourceManager.Owner::(cancelAll) Owner.cancelAll requests {}
Thread-1249::ERROR::2012-03-13 11:49:15,528::dispatcher::103::Storage.Dispatcher.Protect::(run) {'status': {'message': 'Resource timeout: ()', 'code': 851}}
Thread-1322::DEBUG::2012-03-13 11:49:15,546::clientIF::239::Storage.Dispatcher.Protect::(wrapper) [10.35.70.6]

backend log: 

2012-03-13 11:48:38,184 INFO  [org.ovirt.engine.core.vdsbroker.irsbroker.SetStorageDomainDescriptionVDSCommand] (http-0.0.0.0-8443-3) START, SetStorageDomainDescriptionVDSCommand(storagePoolId = 89d4822c-ee2d-4a66-a97f-01facd387a4e, igno
reFailoverLimit = false, compatabilityVersion = null, storageDomainId = 470fcf1a-975b-42ec-a814-13f6f60a7378, description = nfs_change), log id: 77a5ea71
2012-03-13 11:50:38,189 ERROR [org.ovirt.engine.core.vdsbroker.vdsbroker.BrokerCommandBase] (http-0.0.0.0-8443-3) Failed in SetStorageDomainDescriptionVDS method
2012-03-13 11:50:38,189 ERROR [org.ovirt.engine.core.vdsbroker.vdsbroker.BrokerCommandBase] (http-0.0.0.0-8443-3) Error code ResourceTimeout and error message IRSGenericException: IRSErrorException: Failed to SetStorageDomainDescriptionV
DS, error = Resource timeout: ()
2012-03-13 11:50:38,189 ERROR [org.ovirt.engine.core.vdsbroker.irsbroker.IrsBrokerCommand] (http-0.0.0.0-8443-3) IrsBroker::Failed::SetStorageDomainDescriptionVDS due to: IRSErrorException: IRSGenericException: IRSErrorException: Failed 
to SetStorageDomainDescriptionVDS, error = Resource timeout: ()
2012-03-13 11:50:38,210 INFO  [org.ovirt.engine.core.vdsbroker.vdsbroker.SpmStopVDSCommand] (http-0.0.0.0-8443-3) START, SpmStopVDSCommand(vdsId = e71a90de-6c26-11e1-8227-07cb08e4f7e6, storagePoolId = 89d4822c-ee2d-4a66-a97f-01facd387a4e
), log id: 761525da
2012-03-13 11:50:38,223 INFO  [org.ovirt.engine.core.vdsbroker.vdsbroker.SpmStopVDSCommand] (http-0.0.0.0-8443-3) FINISH, SpmStopVDSCommand, log id: 761525da
2012-03-13 11:50:38,223 ERROR [org.ovirt.engine.core.vdsbroker.irsbroker.IrsBrokerCommand] (http-0.0.0.0-8443-3) IRS failover failed - cant allocate vds server
2012-03-13 11:50:38,223 INFO  [org.ovirt.engine.core.vdsbroker.irsbroker.SetStorageDomainDescriptionVDSCommand] (http-0.0.0.0-8443-3) FINISH, SetStorageDomainDescriptionVDSCommand, log id: 77a5ea71
2012-03-13 11:50:38,223 ERROR [org.ovirt.engine.core.bll.storage.UpdateStorageDomainCommand] (http-0.0.0.0-8443-3) Command org.ovirt.engine.core.bll.storage.UpdateStorageDomainCommand throw Vdc Bll exception. With error message VdcBLLExc
eption: org.ovirt.engine.core.vdsbroker.irsbroker.IRSErrorException: IRSGenericException: IRSErrorException: Failed to SetStorageDomainDescriptionVDS, error = Resource timeout: ()
2012-03-13 11:50:38,228 INFO  [org.ovirt.engine.core.bll.storage.SetStoragePoolStatusCommand] (QuartzScheduler_Worker-74) Running command: SetStoragePoolStatusCommand internal: true. Entities affected :  ID: 89d4822c-ee2d-4a66-a97f-01fac
d387a4e Type: StoragePool
2012-03-13 11:50:38,242 ERROR [org.ovirt.engine.core.bll.storage.UpdateStorageDomainCommand] (http-0.0.0.0-8443-3) Transaction rolled-back for command: org.ovirt.engine.core.bll.storage.UpdateStorageDomainCommand.

Comment 1 Dafna Ron 2012-03-13 14:42:48 UTC
RFE opened: https://bugzilla.redhat.com/show_bug.cgi?id=802812

Comment 2 RHEL Program Management 2012-05-05 04:16:21 UTC
Since RHEL 6.3 External Beta has begun, and this bug remains
unresolved, it has been rejected as it is not proposed as
exception or blocker.

Red Hat invites you to ask your support representative to
propose this request, if appropriate and relevant, in the
next release of Red Hat Enterprise Linux.

Comment 4 RHEL Program Management 2012-07-10 07:52:07 UTC
This request was not resolved in time for the current release.
Red Hat invites you to ask your support representative to
propose this request, if still desired, for consideration in
the next release of Red Hat Enterprise Linux.

Comment 5 RHEL Program Management 2012-07-11 01:55:05 UTC
This request was erroneously removed from consideration in Red Hat Enterprise Linux 6.4, which is currently under development.  This request will be evaluated for inclusion in Red Hat Enterprise Linux 6.4.

Comment 6 RHEL Program Management 2012-12-14 07:53:08 UTC
This request was not resolved in time for the current release.
Red Hat invites you to ask your support representative to
propose this request, if still desired, for consideration in
the next release of Red Hat Enterprise Linux.

Comment 8 Allon Mureinik 2014-03-17 09:56:26 UTC
We should drop the description from the domains metadata altogether - this is on our future roadmap.

Comment 9 Allon Mureinik 2014-08-06 12:01:00 UTC
Removing this call is easy, but we need the name for the import SD feature.

Liron - how difficult is it to add this name to the OVF store?

Comment 10 Maor 2014-08-06 12:45:20 UTC
It might still be a problem considering that the domain must be attached to a Data Center to use getImages verb for getting all the disks in the SD including the OVF_Store disk.

I'm not sure, but if we plan to remove the storage pool, maybe we can use getImagesList verb without the need for the Storage Domain to be attached to an initialized Data Center.

Comment 11 Liron Aravot 2015-04-06 08:19:16 UTC
this bug is about setStorageDomain description, which we don't use as part as the import process (we use the volume description) - so unless some customers/gss are using that description we can remove it afaik.

the question is whether we want to eliminate the storage domain description (which means this bug won't be relevant), or have a separate lock for it.
regardless of that, i'd say that the ui shouldn't be blocked for the duration of the vdsm call which always might take up to 3 minutes - so i'd change this part if we leave it.

Comment 12 Yaniv Lavi 2016-01-14 15:37:41 UTC
Do we want to remove this for 4.0?

Comment 13 Allon Mureinik 2016-01-14 15:47:29 UTC
(In reply to Yaniv Dary from comment #12)
> Do we want to remove this for 4.0?
Probably not.

Comment 14 Yaniv Lavi 2016-12-04 14:30:42 UTC
Why is this a RFE and not a bug? Should we close this?

Comment 15 Yaniv Kaul 2016-12-04 15:04:33 UTC
(In reply to Liron Aravot from comment #11)
> this bug is about setStorageDomain description, which we don't use as part
> as the import process (we use the volume description) - so unless some
> customers/gss are using that description we can remove it afaik.

I think in some cases people use the description for important stuff - last backup date, etc.
If we don't show it - we should. If we don't allow to edit it - we should.

> 
> the question is whether we want to eliminate the storage domain description
> (which means this bug won't be relevant), or have a separate lock for it.
> regardless of that, i'd say that the ui shouldn't be blocked for the
> duration of the vdsm call which always might take up to 3 minutes - so i'd
> change this part if we leave it.

I would not remove it, I would allow editing it during import, and that's it.

Comment 16 Yaniv Lavi 2016-12-04 15:26:22 UTC
This is not a RFE, it's a bug.
We can discuss when to fix it and if, but it's not correct to keep it on future.

Comment 17 Yaniv Kaul 2017-02-12 09:37:51 UTC
Tal - being assigned to Allon - is this going to 4.1?

Comment 18 Tal Nisan 2017-02-12 14:16:46 UTC
It's quite a corner case, attempting to change an export domain description while trying to import from it and there's a simple workaround, given the fact no customer encountered it in the 5 years since this bug was opened and the fact that we'd like to eliminated the export domain concept in the future I'd say we should close it as WONTFIX

Comment 19 Yaniv Lavi 2017-02-23 11:25:02 UTC
Moving out all non blocker\exceptions.

Comment 20 Allon Mureinik 2017-03-19 16:32:07 UTC
Definitely not worth the fuss of a z-stream item.
Moving to 4.2, where we can consider what we're doing with the export domain.

Comment 21 Allon Mureinik 2017-06-20 12:03:37 UTC
setStorageDomainDescription takes a shared lock since oVirt 3.3.2 - moving to ON_QA - this should just work, IIUC.

Comment 22 Kevin Alon Goldblatt 2017-07-27 14:21:12 UTC
Verified with the following code:
----------------------------------------------
ovirt-engine-4.2.0-0.0.master.20170723141021.git463826a.el7.centos.noarch
vdsm-4.20.1-218.git1b7671f.el7.centos.x86_64


Verified with the following scenario:
---------------------------------------------
Steps to Reproduce:
1. import vm's from export domain 
2. try to change domain name and or description in rhevm - works fine.


Moving to VERIFIED

Comment 23 Sandro Bonazzola 2017-12-20 11:41:33 UTC
This bugzilla is included in oVirt 4.2.0 release, published on Dec 20th 2017.

Since the problem described in this bug report should be
resolved in oVirt 4.2.0 release, published on Dec 20th 2017, it has been closed with a resolution of CURRENT RELEASE.

If the solution does not work for you, please open a new bug report.