Bug 1278738 - The "virtio_scsi" element isn't populated when a VM is requested
The "virtio_scsi" element isn't populated when a VM is requested
Status: CLOSED CURRENTRELEASE
Product: ovirt-engine
Classification: oVirt
Component: RestAPI (Show other bugs)
3.5.5
Unspecified Unspecified
unspecified Severity low (vote)
: ovirt-4.0.0-alpha
: 4.0.0
Assigned To: Juan Hernández
Shira Maximov
: Reopened
Depends On:
Blocks: 1213937
  Show dependency treegraph
 
Reported: 2015-11-06 05:32 EST by Juan Hernández
Modified: 2016-08-17 10:37 EDT (History)
3 users (show)

See Also:
Fixed In Version: ovirt 4.0.0 alpha1
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2016-08-17 10:37:40 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: Virt
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---
rule-engine: ovirt‑4.0.0+
rule-engine: planning_ack+
rule-engine: devel_ack+
mavital: testing_ack+


Attachments (Terms of Use)


External Trackers
Tracker ID Priority Status Summary Last Updated
oVirt gerrit 50160 master MERGED restapi: Document the use of "All-Content" for VMs Never

  None (edit)
Description Juan Hernández 2015-11-06 05:32:15 EST
When a VM is requested using the RESTAPI the "virtio_scsi" element isn't populated. The expected result should be the following:

  GET /vms/{vm:id}
  <vm>
    ...
    <virtio_scsi>
      <enabled>true|false</enabled>
    </virtio_scsi>
    ...
  </vm>

As a side effect, when using the Python SDK the following code used to disable VirtIO SCSI will fail:

  vm = api.vms.get(name="myvm")
  vm.get_virtio_scsi().set_enabled(False)
  vm.update()

It will fail because "vm.get_virtio_scsi()" returns "None".

As a workaround Python SDK users can do the following:

  vm=api.vms.get(name="myvm")
  vm.set_virtio_scsi(
    params.VirtIO_SCSI(
      enabled=False
    )
  )
  vm.update()
Comment 1 Juan Hernández 2015-11-06 05:51:10 EST
The reason for this missing information is that computing it is expensive, as it requires an additional query per VM, so it has been made optional, it will only be returned when the "All-Content" header is "true":

  GET /vms/{vm:id}
  All-Content: true

  <vm>
    ...
    <virtio_scsi enabled="true|false"/>
    ...
  </vm>

Note also that "enabled" is an attribute, not an inner element as in the description of the bug.

In the Python SDK the "All-Content" header can be activated using the "all_content" parameter of the operation that retrieves the VM:

  vm = api.vms.get(name="myvm", all_content=True)
  vm.get_virtio_scsi().set_enabled(False)
  vm.update()

As this was a design decision and there are workarounds I think that we aren't going to change it.
Comment 2 Michal Skrivanek 2015-12-04 09:59:47 EST
I agree with comment #1. I guess the bug can be closed, right
Comment 3 Petr Spacek 2015-12-04 10:14:41 EST
Honesly I cannot believe that either RHEV or Python SDK will not be fixed. How can I as a mere user know that this workaround is necessary?

Speaking as a regular SDK user, I would like something which acts consistently and does not blow up in unexpected ways.
Comment 4 Juan Hernández 2015-12-09 05:29:13 EST
I this kind of situation we can change the server so that it returns always all the information by default. That hurts performance, so we aren't doing it.

We can improve things for users documenting it. That is what the proposed patch does.

In version 4.0 the documentation will be available from the server, and will look like this:

  https://jhernand.fedorapeople.org/ovirt-api-explorer/#/services/vm/methods/get

This documentation will eventually also added to the SDK itself.

But other than documenting it I don't see how we can make the system more consistent in these regards, unless we always return all the information.
Comment 5 Shira Maximov 2016-08-16 09:39:26 EDT
verified on :
Red Hat Virtualization Manager Version: 4.0.2.6-0.1.el7ev

verification steps:
in REST API:
  GET /vms/{vm:id}
  All-Content: true



result:
<virtio_scsi>
<enabled>true</enabled>
</virtio_scsi>

Note You need to log in before you can comment on or make changes to this bug.