Description of problem: when getting disk parameters through restAPI, the <description> element is missing when the description is an empty string. in other words, the xml that comes back from restAPI sometime has <description> element and sometimes not. Version-Release number of selected component (if applicable): oVirt Engine Version: 3.5.0-0.0.master.20140804172041.git23b558e.el6 VDSM Version: vdsm-4.16.1-6.gita4a4614.el6.x86_64 How reproducible: Happens all the time. Steps to Reproduce: setup: I've used up and running setup with 2 hosts 2 iSCSI SD's , and 1 VM 1. add a new disk to the VM 2. in restAPI read disks, and see that there is no <description> element for that disk 3. live edit the disk description with "Some text". 4. in restAPI read disks, and see that there is a <description> element for that disk with the correct text. 5. live edit the disk description with an empty string. 6. in restAPI read disks, and see that there is no <description> element for that disk Actual results: <description> element sometime appears in xml and sometime not. Expected results: xml structure (elements) should remain the same, elements should not be removed if they have no value, Additional info: ------------------------------------------------------------------------------- Disk with description element: ------------------------------------------------------------------------------- <disk href="/api/vms/934767dd-bbad-4f2e-a372-28aef807713a/disks/8587577e-d731-4e8e-bf3a-4e482a61ec63" id="8587577e-d731-4e8e-bf3a-4e482a61ec63"> <actions> <link href="/api/vms/934767dd-bbad-4f2e-a372-28aef807713a/disks/8587577e-d731-4e8e-bf3a-4e482a61ec63/deactivate" rel="deactivate" /> <link href="/api/vms/934767dd-bbad-4f2e-a372-28aef807713a/disks/8587577e-d731-4e8e-bf3a-4e482a61ec63/activate" rel="activate" /> <link href="/api/vms/934767dd-bbad-4f2e-a372-28aef807713a/disks/8587577e-d731-4e8e-bf3a-4e482a61ec63/export" rel="export" /> <link href="/api/vms/934767dd-bbad-4f2e-a372-28aef807713a/disks/8587577e-d731-4e8e-bf3a-4e482a61ec63/move" rel="move" /> </actions> <name>vm_398664_Disk5</name> <description>SomeTextMsg</description> <link href="/api/vms/934767dd-bbad-4f2e-a372-28aef807713a/disks/8587577e-d731-4e8e-bf3a-4e482a61ec63/permissions" rel="permissions" /> <link href="/api/vms/934767dd-bbad-4f2e-a372-28aef807713a/disks/8587577e-d731-4e8e-bf3a-4e482a61ec63/statistics" rel="statistics" /> <vm href="/api/vms/934767dd-bbad-4f2e-a372-28aef807713a" id="934767dd-bbad-4f2e-a372-28aef807713a" /> <alias>vm_398664_Disk5</alias> <image_id>a2fd56f7-cfa6-4258-a841-37cae992bb73</image_id> <storage_domains> <storage_domain id="a217cac4-c442-4af7-9502-bfc17ca3271c" /> </storage_domains> <size>3221225472</size> <provisioned_size>3221225472</provisioned_size> <actual_size>3221225472</actual_size> <status> <state>ok</state> </status> <interface>virtio</interface> <format>raw</format> <sparse>false</sparse> <bootable>false</bootable> <shareable>false</shareable> <wipe_after_delete>false</wipe_after_delete> <propagate_errors>false</propagate_errors> <active>true</active> <read_only>false</read_only> </disk> ------------------------------------------------------------------------------- Disk without description element: ------------------------------------------------------------------------------- <disk href="/api/vms/934767dd-bbad-4f2e-a372-28aef807713a/disks/8587577e-d731-4e8e-bf3a-4e482a61ec63" id="8587577e-d731-4e8e-bf3a-4e482a61ec63"> <actions> <link href="/api/vms/934767dd-bbad-4f2e-a372-28aef807713a/disks/8587577e-d731-4e8e-bf3a-4e482a61ec63/deactivate" rel="deactivate" /> <link href="/api/vms/934767dd-bbad-4f2e-a372-28aef807713a/disks/8587577e-d731-4e8e-bf3a-4e482a61ec63/activate" rel="activate" /> <link href="/api/vms/934767dd-bbad-4f2e-a372-28aef807713a/disks/8587577e-d731-4e8e-bf3a-4e482a61ec63/export" rel="export" /> <link href="/api/vms/934767dd-bbad-4f2e-a372-28aef807713a/disks/8587577e-d731-4e8e-bf3a-4e482a61ec63/move" rel="move" /> </actions> <name>vm_398664_Disk5</name> <link href="/api/vms/934767dd-bbad-4f2e-a372-28aef807713a/disks/8587577e-d731-4e8e-bf3a-4e482a61ec63/permissions" rel="permissions" /> <link href="/api/vms/934767dd-bbad-4f2e-a372-28aef807713a/disks/8587577e-d731-4e8e-bf3a-4e482a61ec63/statistics" rel="statistics" /> <vm href="/api/vms/934767dd-bbad-4f2e-a372-28aef807713a" id="934767dd-bbad-4f2e-a372-28aef807713a" /> <alias>vm_398664_Disk5</alias> <image_id>a2fd56f7-cfa6-4258-a841-37cae992bb73</image_id> <storage_domains> <storage_domain id="a217cac4-c442-4af7-9502-bfc17ca3271c" /> </storage_domains> <size>3221225472</size> <provisioned_size>3221225472</provisioned_size> <actual_size>3221225472</actual_size> <status> <state>ok</state> </status> <interface>virtio</interface> <format>raw</format> <sparse>false</sparse> <bootable>false</bootable> <shareable>false</shareable> <wipe_after_delete>false</wipe_after_delete> <propagate_errors>false</propagate_errors> <active>true</active> <read_only>false</read_only> </disk>
This seems to be the general behavior of the system (e.g., VM's comment field), and AFAIK, it is by design. Moving to infra to decide how/if this should be handled. Juan - if I've missed anything, feel free to explain what I've missed and move it back.
I'm not aware of any explicit design decision about this. We could, if considered appropriate, change this behavior. However, I think that a robust client should be prepared for both scenarios, and should treat missing and empty descriptions the same. This isn't true in general, as in some situations we may want to do different things for missing and empty elements, but for descriptions we should treat them the same. Anyhow, the RESTAPI doesn't have any logic around this, at least not for VMs: it just takes whatever the backend provides. If the backend gives null for the description the RESTAPI won't generate the <description> element. If the backend gives an empty string instead then the RESTAPI will generate the empty <description></description> element. Whatever we decide the logic should remain in the backend.