Bug 736843

Summary: better error message when rhevm export domain is actually a data domain
Product: [Retired] CloudForms Cloud Engine Reporter: Dave Johnson <dajohnso>
Component: imagefactoryAssignee: Ian McLeod <imcleod>
Status: CLOSED NEXTRELEASE QA Contact: Martin Kočí <mkoci>
Severity: low Docs Contact:
Priority: low    
Version: 1.0.0CC: akarol, brad, dajohnso, deltacloud-maint, dgao, imcleod, morazi, ssachdev, whayutin
Target Milestone: rcKeywords: Triaged
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2014-03-26 13:43:12 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Dave Johnson 2011-09-08 20:27:51 UTC
Description of problem:
====================================
Ran into a issue where pushes were failing with the following error in image-factory.log.  Checked and re-checked pulling in outside help only to figure out that when I created the rhevm export domain, I actually made it of type 'data'.  A more descriptive error would be helpful for end users that run into this.  The error was slightly misleading since the nfs mount was there and mounted.

2011-09-08 19:35:53,165 DEBUG imagefactory.builders.BaseBuilder.FedoraBuilder pid(26328) Message: Exception caught in ImageFactory
2011-09-08 19:35:53,167 DEBUG imagefactory.builders.BaseBuilder.FedoraBuilder pid(26328) Message: Traceback (most recent call last):
  File "/usr/lib/python2.7/site-packages/imagefactory/builders/FedoraBuilder.py", line 1021, in push_image_upload
    self.rhevm_push_image_upload(target_image_id, provider, credentials)
  File "/usr/lib/python2.7/site-packages/imagefactory/builders/FedoraBuilder.py", line 996, in rhevm_push_image_upload
    raise ImageFactoryException("Failed to extract RHEV-M UUID from warehouse POST reponse: %s" % (response))
ImageFactoryException: Failed to extract RHEV-M UUID from warehouse POST reponse: failed
ERROR NFS storage domain for `10.16.120.18:/home/dajo/rhevh-export' not found

Version-Release number of selected component (if applicable):
==================================================================
[root@hp-xw9400-01 rhevm-nfs]# rpm -qa | egrep 'aeolus|iwhd|factory' | sort
aeolus-all-0.4.0-0.20110906160322gitef6e25d.fc15.noarch
aeolus-conductor-0.4.0-0.20110906160322gitef6e25d.fc15.noarch
aeolus-conductor-daemons-0.4.0-0.20110906160322gitef6e25d.fc15.noarch
aeolus-conductor-doc-0.4.0-0.20110906160322gitef6e25d.fc15.noarch
aeolus-configure-2.0.2-2.20110830113535git906f985.fc15.noarch
imagefactory-0.4.1-2.fc15.noarch
iwhd-0.98.15.z3-1.fc15.x86_64
iwhd-0.98.1.d6c4-1.fc15.x86_64
rubygem-aeolus-image-0.1.0-3.20110824113236git15b6922.fc15.noarch
rubygem-imagefactory-console-0.5.0-4.20110824113238gitd9debef.fc15.noarch



Steps to Reproduce:
1. push rhevm image to a data domain
2.
3.

Comment 1 jrd 2011-09-22 18:49:19 UTC
I think this functionality has moved to image factory.  Ian?

Comment 2 wes hayutin 2011-09-28 16:40:48 UTC
making sure all the bugs are at the right version for future queries

Comment 4 wes hayutin 2012-01-12 16:52:43 UTC
adding to sprint tracker

Comment 5 jrd 2012-01-25 15:33:19 UTC
Hmmm.  Somehow this ended up back on my plate.  Ian?  Is this an easy one for 1.0?

Comment 6 Ian McLeod 2012-01-25 19:44:25 UTC
We use an external executable from iwhd to do RHEV-M pushes at the moment.

I'm afraid the existing error reporting is the best we can do in the 1.0 timeframe.

I have a task on my TODO for the next release to pull this functionality into the Factory python code using some newly-available bindings for the RHEV-M API.

Can we keep this open for post-1.0 but remove it from the blockers?

Comment 7 jrd 2012-01-26 15:33:18 UTC
I agree.  Moving to 1.1.

Comment 8 wes hayutin 2012-02-22 23:46:44 UTC
moving version to 1.0.0 .  version = found in version

Comment 9 Mike Orazi 2012-08-15 16:49:38 UTC
This appears to have been auto-approved because flags weren't flipped prior to moving to 1.1.0?.  This is will be considered for a future release.

Comment 10 Mike Orazi 2013-01-22 21:17:22 UTC
Can this be closed out as a side effect of the imgfac2.0/tim?

Comment 11 Ian McLeod 2014-03-26 13:43:12 UTC
Closing as it relates to the now very-deprecated iwhd based RHEV-M pushes.