Bug 2024093

Summary: Satellite shouldn't reject valid volume attributes with "VM volume attributes are not set properly"
Product: Red Hat Satellite Reporter: Evgeni Golov <egolov>
Component: Compute Resources - RHEVAssignee: satellite6-bugs <satellite6-bugs>
Status: CLOSED MIGRATED QA Contact: Satellite QE Team <sat-qe-bz-list>
Severity: medium Docs Contact:
Priority: unspecified    
Version: 6.9.7CC: jbittner, jbreitwe, orabin, rtweed, shwsingh
Target Milestone: UnspecifiedKeywords: MigratedToJIRA, Regression, Triaged
Target Release: Unused   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2024-06-06 01:06:09 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Evgeni Golov 2021-11-17 10:04:29 UTC
Description of problem:
In BZ#1813986 it was reported, that passing "size_gb: <an array>" of volumes_attributes to the compute_resources API will lead to an ISE, and it was fixed by checking that all parameters in "volumes_attributes" are strings (see https://github.com/theforeman/foreman/pull/7873).

This breaks perfectly valid requests that pass "size_gb: 50" (so an Integer) instead of "size_gb: '50'".

Additionally, the request was for a "Meaningful error message, like "Incorrect value of argument 'size_gb'"", but the current implementation just throws "VM volume attributes are not set properly" which neither indicates *which* volume attribute is wrong, neither *what* is wrong about it.

I would consider this a (albeit small) regression in Satellite 6.9 (as this is the first version shipping this code change).

Version-Release number of selected component (if applicable):
Satellite 6.9.7 (but really, anything that's based on Foreman 2.3 or newer)

How reproducible:
100%

Steps to Reproduce:
1. run the following Ansible playbook:
---
- hosts: localhost
  tasks:
    - name: Create compute profiles
      redhat.satellite.compute_profile:
        username: "admin"
        password: "changeme"
        server_url: https://satellite.example.com
        name: test
        compute_attributes:
        - compute_resource: rhevm1
          vm_attrs:
            volumes_attributes:
              0:
                size_gb: 50


Actual results:
fatal: [satellite.example.com]: FAILED! => changed=false 
  error:
    message: 'ERF42-2471 [Foreman::Exception]: VM volume attributes are not set properly'
  msg: 'Error while performing create on compute_attributes: 500 Server Error: Internal Server Error'

Expected results:
It to work.
Or at least give a hint what's wrong.

Additional info:
- I think the API should accept both, Strings and Integers (and probably Booleans?), and only throw an error for *other* types. And then the error should say *which* entry is wrong and what it should look like to be valid.
- In a perfect world, this would be expressed an an Apipie validation in the APIdoc, but I think we don't document possible volumes_attributes at all in the apidoc :(

Comment 1 Evgeni Golov 2021-11-19 09:20:36 UTC
Oh, and throwing that as a 500 Server error is wrong too. It probably should be 422 :unprocessable_entity or something?

Comment 2 Tomer Brisker 2021-11-24 07:50:36 UTC
Created redmine issue https://projects.theforeman.org/issues/33990 from this bug

Comment 3 Brad Buckingham 2023-12-01 18:41:30 UTC
Upon review of our valid but aging backlog the Satellite Team has concluded that this Bugzilla does not meet the criteria for a resolution in the near term, and are planning to close in a month. This message may be a repeat of a previous update and the bug is again being considered to be closed. If you have any concerns about this, please contact your Red Hat Account team.  Thank you.

Comment 5 Brad Buckingham 2024-01-09 19:57:37 UTC
Based upon feedback during auto-closure, leaving this bugzilla open a while longer for additional investigation; however, it may be closed in a future iteration.

Comment 6 Eric Helms 2024-06-06 01:06:09 UTC
This BZ has been automatically migrated to the issues.redhat.com Red Hat Issue Tracker. All future work related to this report will be managed there.

Due to differences in account names between systems, some fields were not replicated.  Be sure to add yourself to Jira issue's "Watchers" field to continue receiving updates and add others to the "Need Info From" field to continue requesting information.

To find the migrated issue, look in the "Links" section for a direct link to the new issue location. The issue key will have an icon of 2 footprints next to it, and begin with "SAT-" followed by an integer.  You can also find this issue by visiting https://issues.redhat.com/issues/?jql= and searching the "Bugzilla Bug" field for this BZ's number, e.g. a search like:

"Bugzilla Bug" = 1234567

In the event you have trouble locating or viewing this issue, you can file an issue by sending mail to rh-issues. You can also visit https://access.redhat.com/articles/7032570 for general account information.