Bug 1716423 - Nonexistent quota can be set
Summary: Nonexistent quota can be set
Alias: None
Product: Red Hat Satellite
Classification: Red Hat
Component: Compute Resources - RHEV
Version: 6.6.0
Hardware: Unspecified
OS: Unspecified
medium vote
Target Milestone: 6.8.0
Assignee: Shira Maximov
QA Contact: Lukáš Hellebrandt
Depends On:
Blocks: 1685949
TreeView+ depends on / blocked
Reported: 2019-06-03 13:24 UTC by Lukáš Hellebrandt
Modified: 2020-10-27 12:58 UTC (History)
6 users (show)

Fixed In Version: foreman-
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Last Closed: 2020-10-27 12:58:35 UTC
Target Upstream Version:

Attachments (Terms of Use)
rhev.log (34.42 KB, text/plain)
2019-10-23 10:12 UTC, Lukáš Hellebrandt
no flags Details
hammer.log (31.32 KB, application/octet-stream)
2019-10-23 10:12 UTC, Lukáš Hellebrandt
no flags Details

System ID Private Priority Status Summary Last Updated
Foreman Issue Tracker 27002 0 Normal Closed Nonexistent quota can be set 2020-10-28 17:16:50 UTC
Foreman Issue Tracker 30175 0 Normal Closed Problem when assigning quota in ovirt 2020-10-28 17:16:50 UTC
Foreman Issue Tracker 30830 0 Normal Closed API - ovirt DC is not saved properly when creating a CR 2020-10-28 17:16:50 UTC
Foreman Issue Tracker 30912 0 Normal Closed API oVirt CR creation with Quota name is not working 2020-10-28 17:16:50 UTC
Red Hat Product Errata RHSA-2020:4366 0 None None None 2020-10-27 12:58:50 UTC

Description Lukáš Hellebrandt 2019-06-03 13:24:37 UTC
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:

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:
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.

Comment 5 Shira Maximov 2019-06-10 06:43:57 UTC
Created redmine issue https://projects.theforeman.org/issues/27002 from this bug

Comment 6 Shira Maximov 2019-09-03 12:48:07 UTC
Lukas, please attach engine logs and hammer logs.

Comment 7 Lukáš Hellebrandt 2019-10-23 10:12:02 UTC
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`.

Comment 8 Lukáš Hellebrandt 2019-10-23 10:12:32 UTC
Created attachment 1628265 [details]

Comment 9 Lukáš Hellebrandt 2019-10-23 10:12:54 UTC
Created attachment 1628266 [details]

Comment 10 Bryan Kearney 2019-11-05 20:43:46 UTC
Upstream bug assigned to ymakias@redhat.com

Comment 11 Bryan Kearney 2019-11-05 20:43:48 UTC
Upstream bug assigned to ymakias@redhat.com

Comment 12 Bryan Kearney 2019-12-11 11:03:24 UTC
Moving this bug to POST for triage into Satellite 6 since the upstream issue https://projects.theforeman.org/issues/27002 has been resolved.

Comment 13 Lukáš Hellebrandt 2020-06-19 14:25:12 UTC
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.

Comment 14 Lukáš Hellebrandt 2020-09-02 15:14:40 UTC
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).

Comment 17 Lukáš Hellebrandt 2020-09-24 12:16:24 UTC
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.

Comment 18 Tomer Brisker 2020-09-29 13:20:14 UTC
Moving back to Modified, fix has been merged upstream (and confirmed by hotfixing testing system, thanks Lukáš!)

Comment 19 Tomer Brisker 2020-09-29 13:23:48 UTC
Connecting redmine issue https://projects.theforeman.org/issues/30912 from this bug

Comment 21 Lukáš Hellebrandt 2020-10-05 13:47:50 UTC
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.

Comment 24 errata-xmlrpc 2020-10-27 12:58:35 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 (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.


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