Bug 1947902 - ansible modules for gathering VM information are incomplete and very slow
Summary: ansible modules for gathering VM information are incomplete and very slow
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Virtualization Manager
Classification: Red Hat
Component: ovirt-ansible-collection
Version: 4.4.3
Hardware: x86_64
OS: Linux
high
high
Target Milestone: ovirt-4.4.7
: ---
Assignee: Martin Necas
QA Contact: Guilherme Santos
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2021-04-09 13:53 UTC by Robert McSwain
Modified: 2024-10-01 17:53 UTC (History)
5 users (show)

Fixed In Version: ovirt-ansible-collection-1.5.0
Doc Type: Bug Fix
Doc Text:
Previously, using an Ansible playbook to fetch virtual machine disk information was slow and incomplete, while the REST API fetched the information faster and more completely. In this release, the Ansible playbook fetches the information completely and quickly.
Clone Of:
Environment:
Last Closed: 2021-07-22 15:26:02 UTC
oVirt Team: Infra
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)
rhv_disks.yml script (1.14 KB, text/plain)
2021-04-09 13:53 UTC, Robert McSwain
no flags Details
REST API command (159 bytes, text/plain)
2021-04-09 13:54 UTC, Robert McSwain
no flags Details


Links
System ID Private Priority Status Summary Last Updated
Github oVirt ovirt-ansible-collection pull 251 0 None open info modules: add follow parameter 2021-05-31 09:04:20 UTC
Red Hat Product Errata RHSA-2021:2866 0 None None None 2021-07-22 15:26:18 UTC

Description Robert McSwain 2021-04-09 13:53:29 UTC
Created attachment 1770621 [details]
rhv_disks.yml script

Description of problem:
I want to get disk info for all my RHV VMs. By default, ovirt_vm_info does not provide that info, but it seems like it's supposed to be possible to get that by requesting it with "fetch_nested".

First, the documentation is unclear how "fetch_nested" and "nested_attributes" are supposed to work. The docs say that "fetch_nested" "will fetch additional data from the API" and that "nested_attributes" "Specifies list of the attributes which should be fetched from the API". It seems to me that means that I should set "fetch_nested" to "True" and set "nested_attributes" to the one I'm interested in, which is "disk_attachments" in this case.

But what seems to happen is that if I set "fetch_ nested" to "True", then it fills out *all* of the previously unpopulated attributes, though just with IDs instead of a whole object. So then I thought that maybe setting "nested_attributes" to "disk_attachments" would limit it, but it does not; it adds an empty "disk_attachments" attribute to the "templates" attribute. Then I realized that made it look for deeper attributes with that name, and I need the "disk" inside "disk_attachments", so I set "nested_attributes" to "disk" and I did get further information about those disks, but it was just "href" and "id" rather than the actual object. I was never able to get deeper info about the disks without iterating over them with a separate module.

Also, I was trying to get that info about all of the VMs in my cluster. Getting a list of VMs without "fetch_nested" enabled took about 5 seconds. When I enabled "fetch_nested", that increased to about 17 minutes. Yes, you're reading that right: an approximately 200x increase in time. A network packet capture makes it appear that it is making a new HTTP request for every nested thing that it's getting data for.

Meanwhile, I tried to use the REST API directly and was able to get all of this information (including the deeper disk info that wasn't accessible with ovirt_vm_info) with a single REST request, using the "follow" parameter, that took about 5 seconds. The "follow" parameter is documented here: http://ovirt.github.io/ovirt-engine-api-model/4.3/#documents/003_common_concepts/follow

So my request is twofold:

* make it so that ovirt_vm_info will provide useful deep info on VMs
* make it so that ovirt_vm_info doesn't take an inordinate amount of time in order to get its info

Attached are:

* a sample Ansible playbook showing all three iterations (plain, with "fetch_nested" alone, and with both "fetch_nested" and "nested_attributes")
* a sample curl command that's requesting equivalent information
* output from both of those


Version-Release number of selected component (if applicable):
RHV 4.4.3

How reproducible:
100%

Steps to Reproduce:
See description/scripts

Actual results:
Output from ansible is not as complete as information gathered by REST API, and taking ~200x longer than with API

Expected results:
Ansible and REST API should provide equal output of information about VMs and equally as quickly.

Comment 2 Robert McSwain 2021-04-09 13:54:59 UTC
Created attachment 1770623 [details]
REST API command

Comment 6 Guilherme Santos 2021-06-29 17:44:46 UTC
Verified on:
ovirt-engine-4.4.7.5-0.9.el8ev.noarch

Steps:
1. Use follows attribute in ovirt_vm_info modulo to gather fetched attributes in ansible:
# ansible localhost -c localhost -m ovirt.ovirt.ovirt_vm_info -a "auth='url=https://`hostname`/ovirt-engine/api username=admin@internal password=<pass> insecure=true' follows=nics.vnic_profile" -v
# ansible localhost -c localhost -m ovirt.ovirt.ovirt_vm_info -a "auth='url=https://`hostname`/ovirt-engine/api username=admin@internal password=<pass> insecure=true' follows=reported_devices" -v

Results:
Infos properly gathered using follow

Comment 12 errata-xmlrpc 2021-07-22 15:26:02 UTC
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 (Low: RHV Engine and Host Common Packages security update [ovirt-4.4.7]), 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/RHSA-2021:2866

Comment 13 Red Hat Bugzilla 2023-09-15 01:33:35 UTC
The needinfo request[s] on this closed bug have been removed as they have been unresolved for 365 days


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