Bug 1460158 - Validation failed: Status is not included in the list
Validation failed: Status is not included in the list
Status: POST
Product: Red Hat CloudForms Management Engine
Classification: Red Hat
Component: Automate (Show other bugs)
5.7.0
Unspecified Unspecified
high Severity high
: GA
: 5.9.0
Assigned To: Greg McCullough
Dave Johnson
: TestOnly, ZStream
Depends On:
Blocks: 1477616 1477617
  Show dependency treegraph
 
Reported: 2017-06-09 05:31 EDT by Gellert Kis
Modified: 2017-08-02 10:04 EDT (History)
11 users (show)

See Also:
Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of:
: 1477616 1477617 (view as bug list)
Environment:
5.7.2.1
Last Closed:
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: Unknown


Attachments (Terms of Use)

  None (edit)
Comment 3 Bronagh Sorota 2017-06-12 10:01:43 EDT
hi Greg,
This looks like an Automate issue. If the root cause turns out to be a Providers issue just punt it back to me.

Thanks,
Bronagh
Comment 11 Greg McCullough 2017-07-28 12:55:06 EDT
A hotfix is possible and we are working on putting a PR together which would then need to be back-ported to 5.7.

We have identified that the MiqProvisionRequestTemplate instance in the miq_requests table in the db has a value of "Denied" for the status column which is causing the issue.  The code change will ensure that this value is not copied when the miq_requests record is copied to the miq_request_tasks table.

There are two possible work-arounds:
1) Recreate the catalog item.  (Customer has verified this is working)
2) Reset the status column to "Ok" for all MiqProvisionRequestTemplate records in the miq_requests table.  If needed this could be performed with a Rails console command like this: "MiqProvisionRequestTemplate.update_all(:status => "Ok")"

My concern is that the root cause is unclear as to how this template record would end up with a denied status.  We have not experienced this issue before and may be related to custom automation logic.  (For example, the service approval workflow.)

My suggestion is that we drop the severity of this issue as the customer appears to be working now and has a work-around and we continue to work with them to try to identify the root cause.  We will also have a PR to prevent this issue going forward at the time of service ordering.
Comment 13 CFME Bot 2017-07-31 10:41:24 EDT
New commit detected on ManageIQ/manageiq/master:
https://github.com/ManageIQ/manageiq/commit/25bdd91cedd3fc3b9d246364040d4aa5d8c7c45f

commit 25bdd91cedd3fc3b9d246364040d4aa5d8c7c45f
Author:     Drew Bomhof <dbomhof@redhat.com>
AuthorDate: Fri Jul 28 17:30:30 2017 -0400
Commit:     Drew Bomhof <dbomhof@redhat.com>
CommitDate: Mon Jul 31 09:51:57 2017 -0400

    Force status removal and default value
    
    When we copy the MiqRequest to MiqRequestTask there is a case where status was not passing
    validation if it was originally set to 'Denied'
    
    This addresses that issue by removing the status column at copy and then setting the default value to 'Ok' in
    the MiqRequestTask
    
    https://bugzilla.redhat.com/show_bug.cgi?id=1460158

 app/models/miq_request.rb       | 14 +++++++++++---
 app/models/miq_request_task.rb  |  1 +
 spec/models/miq_request_spec.rb | 15 +++++++++++++++
 3 files changed, 27 insertions(+), 3 deletions(-)

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