Red Hat Bugzilla – Bug 1439970
[v4 API] Specifying name and vm.disk_attachments returns error 500
Last modified: 2018-05-15 13:43:01 EDT
Description of problem: While creating a template using the API, according to [1] and [2], I have to specify the VM element using it's NAME or it's ID. And it works fine. However, if in the same template create request, I customize the VM disk_attachment, ID works but NAME returns error 500. [1] https://github.com/oVirt/ovirt-engine-api-model/blob/master/src/main/java/services/TemplatesService.java#L44 [2] https://gerrit.ovirt.org/75272 (see BZ#1425295) Examples: A: No disk customization, VM by name: OK ======================================== <template> <name>lala_template_070420171032</name> <vm> <name>test</name> </vm> </template> upload completely sent off HTTP/1.1 202 Accepted B: Disk customization, VM by id: OK =================================== <template> <name>lala_template_070420171020</name> <vm id="064dec9d-733d-46a8-91f8-78e85c6b150e"> <disk_attachments> <disk_attachment> <disk id="901ce7f1-e5c0-4b16-8d0d-ff976bdcb94b"> <format>cow</format> <sparse>true</sparse> </disk> </disk_attachment> </disk_attachments> </vm> </template> upload completely sent off HTTP/1.1 202 Accepted C: Disk customization, VM by name: ERROR ======================================== <template> <name>lala_template_070420171031</name> <vm> <name>test</name> <disk_attachments> <disk_attachment> <disk id="901ce7f1-e5c0-4b16-8d0d-ff976bdcb94b"> <format>cow</format> <sparse>true</sparse> </disk> </disk_attachment> </disk_attachments> </vm> </template> upload completely sent off HTTP/1.1 500 Internal Server Error I also get this on engine.log, spamming all the logs since the first call is made. Engine goes into a error logging frenzy, repeating it all the time. Tons of these non-stop: 2017-04-07 10:33:23,454 ERROR [org.ovirt.engine.api.restapi.util.LinkHelper] (default task-13) [] Can't find relative path for class "org.ovirt.engine.api.resource.TemplateDisksResource", will return null 2017-04-07 10:33:23,501 ERROR [org.ovirt.engine.api.restapi.util.LinkHelper] (default task-10) [] Can't find relative path for class "org.ovirt.engine.api.resource.TemplateDisksResource", will return null 2017-04-07 10:33:23,501 ERROR [org.ovirt.engine.api.restapi.util.LinkHelper] (default task-10) [] Can't find relative path for class "org.ovirt.engine.api.resource.TemplateDisksResource", will return null 2017-04-07 10:33:23,513 ERROR [org.ovirt.engine.api.restapi.util.LinkHelper] (default task-25) [] Can't find relative path for class "org.ovirt.engine.api.resource.TemplateDisksResource", will return null 2017-04-07 10:33:23,513 ERROR [org.ovirt.engine.api.restapi.util.LinkHelper] (default task-25) [] Can't find relative path for class "org.ovirt.engine.api.resource.TemplateDisksResource", will return null 2017-04-07 10:33:23,514 ERROR [org.ovirt.engine.api.restapi.util.LinkHelper] (default task-25) [] Can't find relative path for class "org.ovirt.engine.api.resource.TemplateDisksResource", will return null 2017-04-07 10:33:23,514 ERROR [org.ovirt.engine.api.restapi.util.LinkHelper] (default task-25) [] Can't find relative path for class "org.ovirt.engine.api.resource.TemplateDisksResource", will return null 2017-04-07 10:33:23,520 ERROR [org.ovirt.engine.api.restapi.util.LinkHelper] (default task-9) [] Can't find relative path for class "org.ovirt.engine.api.resource.TemplateDisksResource", will return null 2017-04-07 10:33:23,520 ERROR [org.ovirt.engine.api.restapi.util.LinkHelper] (default task-9) [] Can't find relative path for class "org.ovirt.engine.api.resource.TemplateDisksResource", will return null Right after issuing the API call I already have 500 of those. See: # grep "Can't find relative path for class \"org.ovirt.engine.api.resource.TemplateDisksResource\"" /var/log/ovirt-engine/engine.log | wc -l 504 Version-Release number of selected component (if applicable): rhevm-4.0.7.4-0.1.el7ev.noarch How reproducible: 100%
Looks like it can't follow the vm link if it's by name? <vm id="064dec9d-733d-46a8-91f8-78e85c6b150e"> <disk_attachments> VS: <vm> <name>test</name> <disk_attachments>
I am taking this to investigate it. May need to move to a different team later.
I believe that the proposed patch fixes the issue: restapi: Fix adding customized template with VM name https://gerrit.ovirt.org/75336 Michal, I'd appreciate if your team can take it from here, and target/backport as required.
Germano, the proposed patch fixes the main issue. But I wasn't able to reproduce those log messages that you mention. They are really warnings, not errors, but anyhow they shouldn't flood the log. I'd appreciate if you can re-test, once the main error is fixed, and report back if you see that log flooding.
(In reply to Juan Hernández from comment #4) > Germano, the proposed patch fixes the main issue. But I wasn't able to > reproduce those log messages that you mention. They are really warnings, not > errors, but anyhow they shouldn't flood the log. I'd appreciate if you can > re-test, once the main error is fixed, and report back if you see that log > flooding. Hi Juan and Michal, Thanks. Can we get it on the 4.1 branch? If so I can test it straightforward. FYI, there is no customer hitting this at the moment and it's really easy to workaround (use ID), so not sure about real the need for a zstream.
INFO: Bug status wasn't changed from MODIFIED to ON_QA due to the following reason: [No relevant external trackers attached] For more info please contact: rhv-devops@redhat.com
Verify with: Software version:4.2.0-0.0.master.20171114111003.git7aa1b91.el7.centos Steps: Create template with VM name and custom disk id: <template> <name>template_BZ</name> <vm> <name>golden_env_mixed_virtio_5</name> <disk_attachments> <disk_attachment> <disk id="b45d0d47-4234-4db9-80e0-769dae8cfb34"> <format>cow</format> <sparse>true</sparse> </disk> </disk_attachment> </disk_attachments> </vm> </template> Template created
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHEA-2018:1488