Bug 1797553
| Summary: | [REST-API] exportToPathOnHost call works only synchronously | ||
|---|---|---|---|
| Product: | Red Hat Enterprise Virtualization Manager | Reporter: | Jaroslav Spanko <jspanko> |
| Component: | ovirt-engine | Assignee: | Liran Rotenberg <lrotenbe> |
| Status: | CLOSED ERRATA | QA Contact: | Polina <pagranat> |
| Severity: | medium | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | 4.3.5 | CC: | ahadas, emarcus, lrotenbe, mperina, oliel |
| Target Milestone: | ovirt-4.4.4 | ||
| Target Release: | 4.4.4 | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| Whiteboard: | |||
| Fixed In Version: | ovirt-engine-4.4.4.1 | Doc Type: | Bug Fix |
| Doc Text: |
Previously, when the export VM as OVA command was executed, other operations on the engine were blocked. This made the engine execute operations serially while expected to be parallel.
In this release, engine tasks are executed in parallel, unblocked by the export VM as OVA command.
|
Story Points: | --- |
| Clone Of: | Environment: | ||
| Last Closed: | 2021-02-02 13:58:29 UTC | Type: | Bug |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | Virt | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
(In reply to Jaroslav Spanko from comment #0) > Description of problem: > When call the ExportVmTemplateToOvaCommand class from UI it's given job ID > and all subsequent operations are asynchronous(using ansible playbook). > However, when ExportVmTemplateToOvaCommand class is called using REST-API, > no job ID is given, and all subsequent operations are synchronous. > So Rest-API and UI is doing different things. > > Version-Release number of selected component (if applicable): > ovirt-engine-4.3.7.2-0.1.el7.noarch > ovirt-engine-restapi-4.3.7.2-0.1.el7.noarch > > How reproducible: > 100% > > Steps to Reproduce: > 1. Export template to OVA via REST API and via UI > 2. no job ID is given in case of REST API > 3. in case of UI job ID is given > > Actual results: > UI{asynchronous} and REST API{synchronous} is doing different things > > Expected results: > Both UI and REST API should work in the same way > > Additional info: > ExportToPathOnHost as a REST-API in RHV-M even though its PollingType is > "VDSM_TASKS", it works as "non-async". > The code implementation confirms that the same method is used for all > operations, except that `exportToPathOnHost` only functions synchronously. As per the description, the UI and Rest API do not always work the same way. Is there a reason for not providing the Job ID with the REST API? It could make sense that it is not needed for REST API, but useful for the user via the UI. Possibly an issue with how the status-polling is defined for this task, assigning to myself Can you please explain where the job-id is given in the WebAdmin? When I do this export I don't see any job-id returned by the WebAdmin, perhaps I am looking at the wrong place? verified on ovirt-engine-4.4.4.3-0.5.el8ev.noarch & vdsm-4.40.39-1.el8ev.x86_64. Send asynchronously 4 Rest API requests[1]. Checked that output of 'ps -aux | grep ova' contains simultaneous jobs, like root 199081 1.5 0.0 278804 12484 pts/4 S+ 10:38 0:00 /usr/bin/python3 /root/.ansible/tmp/ansible-tmp-1607503101.7411444-3099168-85240921044165/pack_ova.py vm /var/ova_test1.ova.tmp <?xml ... root 198865 0.2 0.0 278824 12172 pts/2 S+ 10:38 0:00 /usr/bin/python3 /root/.ansible/tmp/ansible-tmp-1607503086.89109-3099080-111263828970658/pack_ova.py vm /var/ova_test4.ova.tmp <?xml ... root 198730 0.1 0.0 278832 12428 pts/1 S+ 10:38 0:00 /usr/bin/python3 /root/.ansible/tmp/ansible-tmp-1607503082.8760166-3099044-48786689210408/pack_ova.py vm /var/ova_test2.ova.tmp <?xml ... [1] POST https://{{host}}/ovirt-engine/api/vms/{VM_id}/export <action> <async>false</async> <directory>/var</directory> <filename>ova_test3.ova</filename> <grace_period> <expiry>10</expiry> </grace_period> <host href="/ovirt-engine/api/hosts/06025d64-ff27-4d9b-805e-745f61ac277e" id="06025d64-ff27-4d9b-805e-745f61ac277e"> <actions> <link href="/ovirt-engine/api/hosts/06025d64-ff27-4d9b-805e-745f61ac277e/refresh" rel="refresh"/> <link href="/ovirt-engine/api/hosts/06025d64-ff27-4d9b-805e-745f61ac277e/activate" rel="activate"/> <link href="/ovirt-engine/api/hosts/06025d64-ff27-4d9b-805e-745f61ac277e/install" rel="install"/> <link href="/ovirt-engine/api/hosts/06025d64-ff27-4d9b-805e-745f61ac277e/deactivate" rel="deactivate"/> <link href="/ovirt-engine/api/hosts/06025d64-ff27-4d9b-805e-745f61ac277e/upgrade" rel="upgrade"/> <link href="/ovirt-engine/api/hosts/06025d64-ff27-4d9b-805e-745f61ac277e/approve" rel="approve"/> <link href="/ovirt-engine/api/hosts/06025d64-ff27-4d9b-805e-745f61ac277e/commitnetconfig" rel="commitnetconfig"/> <link href="/ovirt-engine/api/hosts/06025d64-ff27-4d9b-805e-745f61ac277e/enrollcertificate" rel="enrollcertificate"/> <link href="/ovirt-engine/api/hosts/06025d64-ff27-4d9b-805e-745f61ac277e/fence" rel="fence"/> <link href="/ovirt-engine/api/hosts/06025d64-ff27-4d9b-805e-745f61ac277e/forceselectspm" rel="forceselectspm"/> <link href="/ovirt-engine/api/hosts/06025d64-ff27-4d9b-805e-745f61ac277e/iscsidiscover" rel="iscsidiscover"/> <link href="/ovirt-engine/api/hosts/06025d64-ff27-4d9b-805e-745f61ac277e/iscsilogin" rel="iscsilogin"/> <link href="/ovirt-engine/api/hosts/06025d64-ff27-4d9b-805e-745f61ac277e/unregisteredstoragedomainsdiscover" rel="unregisteredstoragedomainsdiscover"/> <link href="/ovirt-engine/api/hosts/06025d64-ff27-4d9b-805e-745f61ac277e/upgradecheck" rel="upgradecheck"/> <link href="/ovirt-engine/api/hosts/06025d64-ff27-4d9b-805e-745f61ac277e/copyhostnetworks" rel="copyhostnetworks"/> <link href="/ovirt-engine/api/hosts/06025d64-ff27-4d9b-805e-745f61ac277e/setupnetworks" rel="setupnetworks"/> <link href="/ovirt-engine/api/hosts/06025d64-ff27-4d9b-805e-745f61ac277e/syncallnetworks" rel="syncallnetworks"/> </actions> <name>host_mixed_1</name> <comment></comment> <link href="/ovirt-engine/api/hosts/06025d64-ff27-4d9b-805e-745f61ac277e/katelloerrata" rel="katelloerrata"/> <link href="/ovirt-engine/api/hosts/06025d64-ff27-4d9b-805e-745f61ac277e/permissions" rel="permissions"/> <link href="/ovirt-engine/api/hosts/06025d64-ff27-4d9b-805e-745f61ac277e/tags" rel="tags"/> <link href="/ovirt-engine/api/hosts/06025d64-ff27-4d9b-805e-745f61ac277e/affinitylabels" rel="affinitylabels"/> <link href="/ovirt-engine/api/hosts/06025d64-ff27-4d9b-805e-745f61ac277e/nics" rel="nics"/> <link href="/ovirt-engine/api/hosts/06025d64-ff27-4d9b-805e-745f61ac277e/fenceagents" rel="fenceagents"/> <link href="/ovirt-engine/api/hosts/06025d64-ff27-4d9b-805e-745f61ac277e/devices" rel="devices"/> <link href="/ovirt-engine/api/hosts/06025d64-ff27-4d9b-805e-745f61ac277e/hooks" rel="hooks"/> <link href="/ovirt-engine/api/hosts/06025d64-ff27-4d9b-805e-745f61ac277e/storage" rel="storage"/> <link href="/ovirt-engine/api/hosts/06025d64-ff27-4d9b-805e-745f61ac277e/networkattachments" rel="networkattachments"/> <link href="/ovirt-engine/api/hosts/06025d64-ff27-4d9b-805e-745f61ac277e/storageconnectionextensions" rel="storageconnectionextensions"/> <link href="/ovirt-engine/api/hosts/06025d64-ff27-4d9b-805e-745f61ac277e/unmanagednetworks" rel="unmanagednetworks"/> <link href="/ovirt-engine/api/hosts/06025d64-ff27-4d9b-805e-745f61ac277e/externalnetworkproviderconfigurations" rel="externalnetworkproviderconfigurations"/> <link href="/ovirt-engine/api/hosts/06025d64-ff27-4d9b-805e-745f61ac277e/numanodes" rel="numanodes"/> <link href="/ovirt-engine/api/hosts/06025d64-ff27-4d9b-805e-745f61ac277e/statistics" rel="statistics"/> <address>puma42.scl.lab.tlv.redhat.com</address> <auto_numa_status>unknown</auto_numa_status> <certificate> <organization>scl.lab.tlv.redhat.com</organization> <subject>O=scl.lab.tlv.redhat.com,CN=puma42.scl.lab.tlv.redhat.com</subject> </certificate> <cpu> <name>Intel(R) Xeon(R) CPU E5-2630 0 @ 2.30GHz</name> <speed>2802</speed> <topology> <cores>6</cores> <sockets>2</sockets> <threads>2</threads> </topology> <type>Secure Intel SandyBridge Family</type> </cpu> <device_passthrough> <enabled>false</enabled> </device_passthrough> <external_status>ok</external_status> <hardware_information> <family>Server</family> <manufacturer>Dell Inc.</manufacturer> <product_name>PowerEdge C6220</product_name> <serial_number>8KBNFY1</serial_number> <supported_rng_sources> <supported_rng_source>hwrng</supported_rng_source> <supported_rng_source>random</supported_rng_source> </supported_rng_sources> <uuid>4C4C4544-004B-4210-804E-B8C04F465931</uuid> <version></version> </hardware_information> <iscsi> <initiator>iqn.1994-05.com.redhat:puma42</initiator> </iscsi> <kdump_status>disabled</kdump_status> <ksm> <enabled>true</enabled> </ksm> <libvirt_version> <build>0</build> <full_version>libvirt-6.6.0-7.module+el8.3.0+8424+5ea525c5</full_version> <major>6</major> <minor>6</minor> <revision>0</revision> </libvirt_version> <max_scheduling_memory>31815892992</max_scheduling_memory> <memory>33455865856</memory> <numa_supported>true</numa_supported> <os> <custom_kernel_cmdline></custom_kernel_cmdline> <reported_kernel_cmdline>BOOT_IMAGE=(hd0,msdos1)/vmlinuz-4.18.0-240.5.1.el8_3.x86_64 root=/dev/mapper/VolGroup01-root ro nofb default_hugepagesz=1G hugepagesz=1G hugepages=4 hugepagesz=2M hugepages=1024 console=tty0 crashkernel=auto resume=UUID=1c2dbfef-d1cb-4106-9c3c-aebc067c8497 rd.lvm.lv=VolGroup01/root biosdevname=0 console=ttyS1,115200</reported_kernel_cmdline> <type>RHEL</type> <version> <full_version>8.3 - 1.0.el8</full_version> <major>8</major> <minor>3</minor> </version> </os> <port>54321</port> <power_management> <automatic_pm_enabled>true</automatic_pm_enabled> <enabled>false</enabled> <kdump_detection>true</kdump_detection> <pm_proxies/> </power_management> <protocol>stomp</protocol> <reinstallation_required>false</reinstallation_required> <se_linux> <mode>permissive</mode> </se_linux> <spm> <priority>5</priority> <status>none</status> </spm> <ssh> <fingerprint>SHA256:djHP/0OJLtbQ8//fczLxhE5QvFFS2r1xkzbZPwLNHvE</fingerprint> <port>22</port> </ssh> <status>up</status> <summary> <active>0</active> <migrating>0</migrating> <total>1</total> </summary> <transparent_hugepages> <enabled>true</enabled> </transparent_hugepages> <type>rhel</type> <update_available>false</update_available> <version> <build>39</build> <full_version>vdsm-4.40.39-1.el8ev</full_version> <major>4</major> <minor>40</minor> <revision>0</revision> </version> <vgpu_placement>consolidated</vgpu_placement> <cluster href="/ovirt-engine/api/clusters/63dae747-d620-4669-aaee-77c751d3156e" id="63dae747-d620-4669-aaee-77c751d3156e"/> </host> </action> 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 (RHV Engine and Host Common Packages 4.4.z [ovirt-4.4.4]), 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/RHBA-2021:0312 |
Description of problem: When call the ExportVmTemplateToOvaCommand class from UI it's given job ID and all subsequent operations are asynchronous(using ansible playbook). However, when ExportVmTemplateToOvaCommand class is called using REST-API, no job ID is given, and all subsequent operations are synchronous. So Rest-API and UI is doing different things. Version-Release number of selected component (if applicable): ovirt-engine-4.3.7.2-0.1.el7.noarch ovirt-engine-restapi-4.3.7.2-0.1.el7.noarch How reproducible: 100% Steps to Reproduce: 1. Export template to OVA via REST API and via UI 2. no job ID is given in case of REST API 3. in case of UI job ID is given Actual results: UI{asynchronous} and REST API{synchronous} is doing different things Expected results: Both UI and REST API should work in the same way Additional info: ExportToPathOnHost as a REST-API in RHV-M even though its PollingType is "VDSM_TASKS", it works as "non-async". The code implementation confirms that the same method is used for all operations, except that `exportToPathOnHost` only functions synchronously.