Description of problem: you can't query the api which user created a vm. you can do this via "events", however events are just stored for the last 30 days. as per http://lists.ovirt.org/pipermail/users/2014-November/029014.html this information is already stored in the database and should therefore be easily exposed via api. Version-Release number of selected component (if applicable): 3.5 How reproducible: always Steps to Reproduce: 1. 2. 3. Actual results: Expected results: query vm to see who created it Additional info: filed RFE according to mailing list request please consider backporting to 3.5.z if possible
Yaniv, is this information available in some existing report?
As per the ML-Thread, this is already stored in the DB: We have it on database, but I don't see it exposed on API: engine=# select vm_static.vm_name, users.name, users.domain from vm_static, users where vm_static.created_by_user_id = users.user_id; -[ RECORD 1 ]----- vm_name | vm01 name | admin domain | internal -[ RECORD 2 ]----- vm_name | test name | admin domain | internal ... Does this provide the needed info?
No Sven, I was asking Yaniv Dary if there is an existing ovirt-reports report that contains this information, as may useful as a workaround. Anyhow it is good to have the query in the bug, thanks.
*** Bug 1161629 has been marked as a duplicate of this bug. ***
(In reply to Juan Hernández from comment #1) > Yaniv, is this information available in some existing report? Yes, via ad hoc and inventory I believe.
need to remember that the user id might be invalid after some time.. (creating user can be deleted..)
(In reply to Omer Frenkel from comment #6) > need to remember that the user id might be invalid after some time.. > (creating user can be deleted..) I the reports it's kept forever, so this might be the best solution.
so...the reporting solves this in a better way....
Don't know what info you need. Do you need the information if the provided information via reports does solve this? I would say no for the following reasons: Reports do not offer any (REST) api (I know of). I do not even have reports installed. It would at best be very clumsy to automate such a data retrieval process, as I understand it, reports generates pdfs and you could parse them for the information this BZ requests but it would still be a dirty hack. This BZ was about providing information witch is already stored in the DB via the already implemented apis, in order to process and query this information in a dynamic and automated fashion. I don't know if reports can provide this but I would rather use the existing rest api than install yet-another-software. I hope this was the information you requested.
just need to bear in mind the limitation when the user is removed/renamed
this is unlikely to be picked up for maintenance branch, so moving target release to 3.6
This bug did not make it in time for 3.6 release, moving into the next one
Target release should be placed once a package build is known to fix a issue. Since this bug is not modified, the target version has been reset. Please use target milestone to plan a fix for a oVirt release.
The fix for this issue should be included in oVirt 4.1.0 beta 1 released on December 1st. If not included please move back to modified.
Verify with Engine: 4.1.0-.2.master.20161213122836.git2cd5587.el7.centos Host: OS Description:Red Hat Enterprise Linux Server 7.3 (Maipo) Kernel Version:3.10.0 - 514.el7.x86_64 KVM Version:2.6.0 - 27.1.el7 LIBVIRT Version:libvirt-2.0.0-10.el7 VDSM Version: vdsm-4.18.999-1138.git6c51957.el7.centos Polarion run: https://polarion.engineering.redhat.com/polarion/#/project/RHEVM3/testrun?id=VIRT%20Search%20Functionality&tab=records&result=passed