Created attachment 1235257 [details] logs: engine.log, image-proxy.log, vdsm.log Description of problem: When starting an upload using python-sdk the following error appears in engine.log: 2016-12-25 10:42:42,918 ERROR [org.ovirt.engine.api.restapi.util.LinkHelper] (default task-9) [] Can't find relative path for class "org.ovirt.engine.api.resource.ImagesResource", will return null Version-Release number of selected component (if applicable): vdsm-4.18.21-1.el7ev.x86_64 ovirt-engine-4.0.6-0.1.el7ev.noarch How reproducible: 100% Steps to Reproduce: Start an upload using python sdk (raw disk to nfs storage type) Actual results: The following error appears in log: 2016-12-25 10:42:42,918 ERROR [org.ovirt.engine.api.restapi.util.LinkHelper] (default task-9) [] Can't find relative path for class "org.ovirt.engine.api.resource.ImagesResource", will return null Expected results: No errors in engine log Additional info: Not sure about the impact - the upload itself finishes eventually and the data transferred is correct.
Juan, I'm not sure it is directly related to image upload, do you identify this error? or do you think it is related to the backend implementation of the image transfer model?
(In reply to Amit Aviram from comment #1) > Juan, I'm not sure it is directly related to image upload, do you identify > this error? or do you think it is related to the backend implementation of > the image transfer model? It isn't. I've seen several "Can't find relative path for class "org.ovirt.engine.api.resource..." errors in various reports.
It is related to the image upload, but not an important issue. This message appears when the API isn't able to find a path to build a link to an object that you are returning. For example, if you return something like this: <image_transfer> <image id="123"/> ... </image> Then the API will try to complete the "image" link, adding the "href" attribute: <image_transfer> <image id="123" href="/ovirt-engine/api/storagedomains/456/images/123"/> ... </image_transfer> But in this case the API isn't able to calculate that "href", probably because we miss some metadata in the "LinkHelper" class. The log message is marked as ERROR so that we don't miss these issues. It should probably be softened, to WARNING. Ori, can you please take a look at this?
patch posted: https://gerrit.ovirt.org/69222
The proposed patch has been merged, so the error won't appear in the log. However, the link to the image won't be created correctly, as the API has now way to know what is the storage domain that the image belongs to. If we want to have that link created correctly then at some point the code needs to set the 'StorageDomain' attribute of the image, probably in the 'addParents' method: @Override protected ImageTransfer addParents(ImageTransfer transfer) { Image image = transfer.getImage(); if (image != null) { StorageDomain sd = image.getStorageDomain(); if (sd == null) { sd = new StorageDomain(); transfer.setStorageDomain(sd); } String sdId = ...; sd.setId(sdId); } return transfer; } The key point here, and the thing that the API can't do automatically, is determining the identifier of the storage domain. I think we can consider this bug fixed, even without the correct link. If you disagree please change it to ASSIGNED, or create a new bug requesting the fix of the link.
Verified (uploaded disk using python sdk 4.1.3) Used builds: ovirt-engine-4.2.0-0.0.master.20170721095131.git9f5e90c.el7.centos.noarch ovirt-imageio-common-1.1.0-0.201706250653.git86d47ac.el7.centos.noarch ovirt-imageio-proxy-1.1.0-0.201706250653.git86d47ac.el7.centos.noarch ovirt-imageio-daemon-1.1.0-0.201706250653.git86d47ac.el7.centos.noarch ovirt-engine-restapi-4.2.0-0.0.master.20170721095131.git9f5e90c.el7.centos.noarch vdsm-4.20.1-218.git1b7671f.el7.centos.x86_64
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.