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.
Created attachment 1770623 [details] REST API command
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
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
The needinfo request[s] on this closed bug have been removed as they have been unresolved for 365 days