Description of problem: In Hammer, I can specify anything in --ovirt-quota, even if quota with that ID doesn't actually exist. When viewing the CR in WebUI, the first quota in the list of existing quotas is shown. However, when trying to create a host on that CR, you get the following error in WebUI and a quite useless traceback: "Failed to create a compute testrhevH1 (RHV) instance glen-krick.example.com: HTTP response code is 404. The response body is empty. " How reproducible: Deterministic Steps to Reproduce: 1. # hammer compute-resource update --name <current_CR_name> --ovirt-quota <nonexistent_quota_id> 2. In WebUI, try to create a host on the CR Actual results: 404 In the database, there are entries with the nonexistent quota. Expected results: The hammer command should have failed in the first place. Additional info: This is only well debuggable using RHEV's log files.
Created redmine issue https://projects.theforeman.org/issues/27002 from this bug
Lukas, please attach engine logs and hammer logs.
Attaching results of `tail -F -n0 /var/log/ovirt-engine/engine.log /var/log/httpd/* > rhev.log` (grep for 404). Nothing in Hammer log, Hammer just says "Compute resource updated.". Attaching results of `hammer -d compute-resource update --name testrhev --ovirt-quota nonexistentquotaid2 > hammer.log`.
Created attachment 1628265 [details] rhev.log
Created attachment 1628266 [details] hammer.log
Upstream bug assigned to ymakias
Moving this bug to POST for triage into Satellite 6 since the upstream issue https://projects.theforeman.org/issues/27002 has been resolved.
FailedQA with Sat 6.8 snap 5.0. It's not possible to set nonexistent quota anymore, attempt to do so leads to: "Could not update the compute resource: ERF42-8149 [Foreman::Exception]: nonexistentquota is not valid, enter id or name". However, It's not possible to set quota at all, specifying any valid value leads to the first quota in the list being used. Furthermore, I find this part suspicious: "argument_list.detect { |a| a.name == argument }.try(:id) || argument" , it's line 299. Does it mean that when there is a quota with a name that is the same as another quota's ID, the name is preferred for selection? It's acceptable since quota names are unique within a cluster but seems kinda counterintuitive to me.
Failed with Sat 6.8 snap 13.1 since I observe the same behavior as described in comment 13. Example: # hammer -v -u admin -p changeme --output=csv compute-resource create --name="rhevH1" --provider="Ovirt" --user="admin@internal" --password="<password>" --datacenter="5aaaaa41-035d-0157-0166-00000000030b" --url="https://<FQDN>/ovirt-engine/api" --ovirt-quota="e3fd98c3-84dc-4959-9309-4c4b124654e7" --locations="Default Location" --organizations="Default Organization" Compute resource created.,7,rhevH1 # hammer -v -u admin -p changeme --output=csv compute-resource create --name="rhevH2" --provider="Ovirt" --user="admin@internal" --password="<password>" --datacenter="5aaaaa41-035d-0157-0166-00000000030b" --url="https://<FQDN>/ovirt-engine/api" --ovirt-quota="lhellebr" --locations="Default Location" --organizations="Default Organization" Compute resource created.,8,rhevH2 => In WebUI, both CRs have Quota ID == Default (which is the first in the list).
FailedQA again with Sat 6.8 snap 17. Quota can now be set using uuid. When using name and the name is invalid, the error is correctly shown: "ERF42-9496 [Foreman::Exception]: lhellebr-nonexistent is not valid, enter id or name" However, when using name and the name is valid, default (first in the list) quota is still selected (as verified through WebUI). This is the basic scenario. To reproduce, just try to set some quota that is not first in the list, using its name.
Moving back to Modified, fix has been merged upstream (and confirmed by hotfixing testing system, thanks Lukáš!)
Connecting redmine issue https://projects.theforeman.org/issues/30912 from this bug
Verified with Sat 6.8 snap 18. Used reproducer from OP, tried {create,update}x{uuid,name}x{valid,invalid} and everything works as expected.
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 (Important: Satellite 6.8 release), 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-2020:4366