Note: This bug is displayed in read-only format because the product is no longer active in Red Hat Bugzilla.

Bug 1183995

Summary: [RFE] Allow force attaching an export domain with stale pool meta-data by turning it into a data domain
Product: [oVirt] ovirt-engine Reporter: Ori Gofen <ogofen>
Component: Frontend.WebAdminAssignee: Maor <mlipchuk>
Status: CLOSED DUPLICATE QA Contact: Raz Tamir <ratamir>
Severity: high Docs Contact:
Priority: unspecified    
Version: 3.5.0CC: acanan, amureini, bugs, gklein, lsurette, mlipchuk, rbalakri, Rhev-m-bugs, srevivo, ykaul, ylavi
Target Milestone: ---Keywords: FutureFeature, Reopened
Target Release: ---Flags: ylavi: ovirt-future?
rule-engine: planning_ack?
rule-engine: devel_ack?
rule-engine: testing_ack?
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2016-12-06 09:22:04 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: Storage RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On:    
Bug Blocks: 1004316    
Attachments:
Description Flags
logs none

Description Ori Gofen 2015-01-20 11:55:09 UTC
Created attachment 981806 [details]
logs

Description of problem:
Importing an "old" Export Domain to a new setup fails.

engine logs:
2015-01-20 13:24:53,012 ERROR [org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector] (ajp-/127.0.0.1:8702-2) [43534a79] Correlation ID: 43534a79, Job ID: f9314558-51e7-49f4-a4de-ecafbb6da7db, Call Stack: null, Custom Event ID: -1, Message: Failed to attach Storage Domain export to Data Center Default. (User: admin)
2015-01-20 13:24:53,016 INFO  [org.ovirt.engine.core.bll.storage.AttachStorageDomainToPoolCommand] (ajp-/127.0.0.1:8702-2) [43534a79] Lock freed to object EngineLock [exclusiveLocks= key: 866ed921-b706-4852-b36c-bb5c16974694 value: STORAGE
, sharedLocks= ]

vdsm logs:
 operation mutex
Thread-4795::ERROR::2015-01-20 13:24:52,393::dispatcher::76::Storage.Dispatcher::(wrapper) {'status': {'message': "Storage domain already attached to pool: u'domain=866ed921-b706-4852-b36c-bb5c16974694, pool=00000002-0002-0002-0002-000000000089'", 'code': 380}}
Thread-4814::DEBUG::2015-01-20 13:24:52,394::lvm::502::Storage.OperationMutex::(_invalidateAllVgs) Operation 'lvm invalidate operation' released the operation mutex


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


How reproducible:


Steps to Reproduce:
1.
2.
3.

Actual results:


Expected results:


Additional info:

Comment 2 Maor 2015-01-20 17:08:06 UTC
export domain is not supported on multiple storage pools.

Comment 3 Ori Gofen 2015-01-20 17:43:06 UTC
(In reply to Maor from comment #2)
> export domain is not supported on multiple storage pools.

Maor, thanx for the quick reply, first of all, as you well know, every Import operation is performed on multiple storage pools, so what you are basically saying is Export domain cannot be imported(or ImportDomain feature does not support NFS Export domain).

Well, according to import domain documentation this operation is very well supported and it's mentioned several times.

http://www.ovirt.org/Features/ImportStorageDomain#General_Functionality

"The user flow for importing NFS Storage Domain, will be similar to importing Export/ISO domain.
The user will enter the path of the storage domain and will start the import process."

"General Functionality
*    The feature should be fully supported from oVirt 3.5.
...
*    Attach of a Storage domain from a disaster environment, which its meta data      still indicates it is attached to another Data Center, is supported for 3.5   Data Center.
"
and I can go on, please do not close this as "NOTABUG" as it is on any case a bug, or RFE, professionally I believe it's the first option.

Comment 4 Allon Mureinik 2015-01-20 18:18:58 UTC
(In reply to Ori Gofen from comment #3)
> (In reply to Maor from comment #2)
> > export domain is not supported on multiple storage pools.
> 
> Maor, thanx for the quick reply, first of all, as you well know, every
> Import operation is performed on multiple storage pools
What?
I think we have our wires crossed somewhere.
The only SD that can be attached to several pools AT ONCE is an ISO domain.

Comment 5 Ori Gofen 2015-01-21 10:05:07 UTC
Allon, not at once, the flow consist from one pool which have been destroyed and one which is active, a regular ImportDomain operation nothing special.

Comment 6 Allon Mureinik 2015-01-21 12:33:13 UTC
So this is the flow we had since 3.1.

I agree it's worth considering having feature parity between data and export domains, but this was not the requirement for 3.5.0.
Pushing out to 3.6.0 to reconsider. 

Maor - can you please link the kbase article for the manual procedure?

Comment 7 Maor 2015-01-21 13:03:23 UTC
Export Domain is not related to the Import Storage Domain feature.
The ImportStorageDomain is only related to Data Storage Domains as described in the summary of the bug, http://www.ovirt.org/Features/ImportStorageDomain#Summary.

Since we want eventually to get rid of the export Storage Domain, I dont think there is a reason to make it an RFE.
(see https://bugzilla.redhat.com/show_bug.cgi?id=924834#c11)

maybe an appropriate RFE might be to change export domain to be a Data Storage Domain to make it compatible with the ImportStorageDomain feature, but this is  a whole different bug IMHO.

Comment 8 Ori Gofen 2015-01-21 13:57:44 UTC
Well I respect you'r humble opinion Maor, please take into consideration that a lot of our major costumers use export domain to implement CloudForms with Rhevm, as well documented at https://access.redhat.com/documentation/en-US/CloudForms/3.1/html/Installing_CloudForms_on_Red_Hat_Enterprise_Virtualization/sect-Installing_CloudForms.html , uploading an image to export domain is the default way to do it today and while OvfStore provides solutions to most "ExportDomain functionalities", this flow can only be executed with ExportDomain.

Comment 9 Ori Gofen 2015-01-25 12:40:15 UTC
Update to this RFE, after a discussion with Maor, about the desired flow that handles this issue, it was agreed that importing an export domain operation should turn the export domain to data domain before importing.
the result will be an Nfs data domain that contains all it's recovered entities.

Comment 10 Allon Mureinik 2015-01-25 17:18:22 UTC
(In reply to Ori Gofen from comment #9)
> Update to this RFE, after a discussion with Maor, about the desired flow
> that handles this issue, it was agreed that importing an export domain
> operation should turn the export domain to data domain before importing.
> the result will be an Nfs data domain that contains all it's recovered
> entities.
It should be OPTIONAL to do so.
We definitely don't want to "blindly" convert domain types.

Comment 15 Yaniv Lavi 2016-12-06 09:22:04 UTC

*** This bug has been marked as a duplicate of bug 1130991 ***