Hide Forgot
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.
I think this functionality has moved to image factory. Ian?
making sure all the bugs are at the right version for future queries
adding to sprint tracker
Hmmm. Somehow this ended up back on my plate. Ian? Is this an easy one for 1.0?
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?
I agree. Moving to 1.1.
moving version to 1.0.0 . version = found in version
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.
Can this be closed out as a side effect of the imgfac2.0/tim?
Closing as it relates to the now very-deprecated iwhd based RHEV-M pushes.