Description of problem: We have this QE test failing on Check_xsd_schema_validations: http://jenkins.qa.lab.tlv.redhat.com:8080/view/Compute/view/3.4-git/view/Virt/job/3.4-git-compute-virt-payloads-rest-nfs/lastCompletedBuild/testReport/General/085-Check%20xsd%20schema%20validations/Check_xsd_schema_validations/ kianku's findings: Problem is that VM object is built with both 'type' & 'data' parameters, as follows, while only one of them should be chosen: <initialization> <configuration> <type>ovf</type> <data><?xml version='1.0' encoding='UTF-8'?><ovf:Envelop From api.xsd: <xs:element name="configuration" type="Configuration"/> <xs:complexType name="Configuration"> <xs:choice> <xs:element name="type" type="xs:string" minOccurs="0" maxOccurs="1"/> <xs:element name="data" type="xs:string" minOccurs="0" maxOccurs="1"/> </xs:choice> </xs:complexType> Version-Release number of selected component (if applicable): ovirt-engine-3.4.0-0.11.beta3.el6.noarch This bug didn't exist on: ovirt-engine-3.4.0-0.5.beta1.el6.noarch but I can't tell the exact point of time it was introduced. How reproducible: 100% (On this test)
This failure happens also in regression mixed test that is QE/CI tier 0. Raising priority to urgent
Note that this change in the schema was done in 3.3.0, so it should happen there as well.
The solution is to change the schema so that the presence of both "type" and "data" is allowed, as both are needed.
Juan, I rechecked 3.3.1 (rhevm-3.3.1-0.48.el6ev.noarch) regression mixed job (create vm part) and it seems that this change doesn't appear there, maybe this change was only in ovirt and not cherry-picked to rhevm?: 2014-02-25 21:44:13,732 - MainThread - vms - DEBUG - Response body for CREATE request is: <vm href="/api/vms/6c4d770e-7b39-4b8e-896c-67be97a8097a" id="6c4d770e-7b39-4b8e-896c-67be97a8097a"> <actions> <link href="/api/vms/6c4d770e-7b39-4b8e-896c-67be97a8097a/ticket" rel="ticket"/> <link href="/api/vms/6c4d770e-7b39-4b8e-896c-67be97a8097a/cancelmigration" rel="cancelmigration"/> <link href="/api/vms/6c4d770e-7b39-4b8e-896c-67be97a8097a/migrate" rel="migrate"/> <link href="/api/vms/6c4d770e-7b39-4b8e-896c-67be97a8097a/move" rel="move"/> <link href="/api/vms/6c4d770e-7b39-4b8e-896c-67be97a8097a/detach" rel="detach"/> <link href="/api/vms/6c4d770e-7b39-4b8e-896c-67be97a8097a/export" rel="export"/> <link href="/api/vms/6c4d770e-7b39-4b8e-896c-67be97a8097a/shutdown" rel="shutdown"/> <link href="/api/vms/6c4d770e-7b39-4b8e-896c-67be97a8097a/start" rel="start"/> <link href="/api/vms/6c4d770e-7b39-4b8e-896c-67be97a8097a/stop" rel="stop"/> <link href="/api/vms/6c4d770e-7b39-4b8e-896c-67be97a8097a/suspend" rel="suspend"/> </actions> <name>restvm_templates</name> <link href="/api/vms/6c4d770e-7b39-4b8e-896c-67be97a8097a/applications" rel="applications"/> <link href="/api/vms/6c4d770e-7b39-4b8e-896c-67be97a8097a/disks" rel="disks"/> <link href="/api/vms/6c4d770e-7b39-4b8e-896c-67be97a8097a/nics" rel="nics"/> <link href="/api/vms/6c4d770e-7b39-4b8e-896c-67be97a8097a/cdroms" rel="cdroms"/> <link href="/api/vms/6c4d770e-7b39-4b8e-896c-67be97a8097a/snapshots" rel="snapshots"/> <link href="/api/vms/6c4d770e-7b39-4b8e-896c-67be97a8097a/tags" rel="tags"/> <link href="/api/vms/6c4d770e-7b39-4b8e-896c-67be97a8097a/permissions" rel="permissions"/> <link href="/api/vms/6c4d770e-7b39-4b8e-896c-67be97a8097a/statistics" rel="statistics"/> <link href="/api/vms/6c4d770e-7b39-4b8e-896c-67be97a8097a/reporteddevices" rel="reporteddevices"/> <link href="/api/vms/6c4d770e-7b39-4b8e-896c-67be97a8097a/watchdogs" rel="watchdogs"/> <type>desktop</type> <status> <state>down</state> </status> <memory>1073741824</memory> <cpu> <topology sockets="1" cores="1"/> </cpu> <cpu_shares>0</cpu_shares> <os type="other"> <boot dev="hd"/> </os> <high_availability> <enabled>false</enabled> <priority>0</priority> </high_availability> <display> <type>spice</type> <monitors>1</monitors> <single_qxl_pci>false</single_qxl_pci> <allow_override>false</allow_override> <smartcard_enabled>false</smartcard_enabled> </display> <cluster href="/api/clusters/bd3e7d51-009a-4efc-9c92-d1df3b91aa61" id="bd3e7d51-009a-4efc-9c92-d1df3b91aa61"/> <template href="/api/templates/00000000-0000-0000-0000-000000000000" id="00000000-0000-0000-0000-000000000000"/> <creation_time>2014-02-25T21:44:13.016+02:00</creation_time> <origin>ovirt</origin> <stateless>false</stateless> <delete_protected>false</delete_protected> <console enabled="false"/> <placement_policy> <affinity>migratable</affinity> </placement_policy> <memory_policy> <guaranteed>1073741824</guaranteed> <ballooning>true</ballooning> </memory_policy> <usb> <enabled>false</enabled> </usb> <virtio_scsi enabled="true"/> </vm>
The change in the schema should be in 3.3 as well. Please check /api?schema and look for the complex type "Configuration", it will be like in the description of the bug: <xs:complexType name="Configuration"> <xs:choice> <xs:element name="type" type="xs:string" minOccurs="0" maxOccurs="1"/> <xs:element name="data" type="xs:string" minOccurs="0" maxOccurs="1"/> </xs:choice> </xs:complexType> It wasn't failing the tests because the functionality that actually uses these elements for output was only added in 3.4. So the schema was wrong, but nobody noticed because it wasn't used to generate output documents.
This BZ should be fixed in oVirt 3.4.0 RC
verified with downstream build rhevm-3.4.0-0.3
this is an automated message: moving to Closed CURRENT RELEASE since oVirt 3.4.0 has been released