Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 1512133 - Zombie Service requests
Summary: Zombie Service requests
Alias: None
Product: Red Hat CloudForms Management Engine
Classification: Red Hat
Component: UI - OPS
Version: 5.9.0
Hardware: Unspecified
OS: Unspecified
Target Milestone: GA
: 5.9.0
Assignee: Milan Zázrivec
QA Contact: Shveta
: 1512390 (view as bug list)
Depends On:
TreeView+ depends on / blocked
Reported: 2017-11-10 23:57 UTC by Kedar Kulkarni
Modified: 2018-01-10 20:18 UTC (History)
12 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Last Closed: 2018-01-10 15:04:11 UTC
Category: Bug
Cloudforms Team: CFME Core
Target Upstream Version:

Attachments (Terms of Use)
Screenshot (deleted)
2017-11-10 23:57 UTC, Kedar Kulkarni
no flags Details

Description Kedar Kulkarni 2017-11-10 23:57:02 UTC
Created attachment 1350717 [details]

Description of problem:
In the Service requests list some Zombie Requests can be seen in the list of "Requests" on Services-> Requests. By zombie, I mean the service that is not ordered and hangs it there without Approval all the time. In other words, SOMETIMES when I order 1 service, 2 service requests are shown in Requests list. This happens when Service is ORDERED VIA OPS UI.

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
1.Create a Service Catalog and Service Catalog item to provision a VM on provider(VMware in my case) 
2.Order the Service from within OPS UI.
3.Navigate to Services -> Requests. 

Actual results:
Multiple requests are shown for single order

Expected results:
Only 1 request should be shown for each service order.

Additional info:

Comment 3 Greg McCullough 2017-11-14 23:27:41 UTC
*** Bug 1512390 has been marked as a duplicate of this bug. ***

Comment 4 Greg McCullough 2017-11-14 23:31:45 UTC
This is a regression.  As part of service provisioning for vendor catalog items (like VMware) we create a MiqProvisionRequestTemplate object in the miq_requests table.  This has always been a hidden object and the screenshot is showing that it is now visible in the Services -> Requests list-view.

Request State is "Pending" and Request Type is "VM Provision Template".  These items should be hidden.

Comment 7 Milan Zázrivec 2017-12-15 15:06:38 UTC
Unfortunately, I cannot reproduce this problem locally. After ordering
a service, the request list screen looks OK.

Is there perhaps an appliance or a database I can use?


Comment 9 Milan Zázrivec 2018-01-04 18:08:52 UTC
I was not able to reproduce the described problem, not even with the DB and appliance provided

I still see just ServiceTemplateProvisionRequest type of requests in the rendered screen (with
both the appliance and the DB provided).

Nevertheless, just by reading the code, the above problem should not be happening: we explicitly
list types of request that we want to render and MiqProvisionRequestTemplate is not one of them.

The theory here is that either there's some other pathway to get to that screen (other than what's
described in the initial comment) or maybe that the report_data() does not honor the options (filter)
passed in entirely under certain circumstances and it simply returns all types of requests.

Comment 10 Kedar Kulkarni 2018-01-05 00:23:42 UTC
Milan, Please disregard the previous comments. I have tried to reproduce zombie requests in a consistent way and I found a path to do so. I tried it with latest downstream appliance I am going to attach a BlueJeans Recording as soon as it is processed. I created 3 appliances and tried the exact same steps and I was able to find requests in "Pending" state as soon as I created Catalog item. Important thing here is, I just "Created" the service catalog item and never "ordered" it. As far as initial comment and screenshot is concerned, I could not reproduce it viably either. So, while looking at requests list might not show zombie requests, but manually typing in the URL does show those requests.

Comment 12 Milan Zázrivec 2018-01-05 12:48:19 UTC
The problem as it is described in the previous two comments is not really a problem (or a bug),
since you're manually editing the browser URL and reaching a screen, which otherwise would not
be reachable just by plain navigation in our UI.

We could make a fix to stop rendering these requests (i.e. requests which are ordinarily hidden,
but can be seen by explicitly entering the correct URL), but this certainly is not a high priority
problem or a blocker. Not unless this is a security problem, which I doubt.

Comment 14 Kedar Kulkarni 2018-01-09 19:53:23 UTC
This bug is also present in 5.8.3, please clone it for 5.8 stream.

Comment 15 Greg McCullough 2018-01-09 20:03:43 UTC
Adding my thoughts on this: the modeling of the requests is such that we add template requests into the table which require an ID.  There are other types of requests that go into this table that are not shown in the Service -> Requests view.  Automation Requests for example.

The product refactoring required to ensure sequential IDs is prohibitively high so I do not see that as a viable option.

There is no guarantee that Request IDs will be sequential and we can document that if that is what is needed here.

My preference for this issue is that it gets closed as "Won't Fix" unless there is some UI solution in the works.  From a backend perspective the models and database tables are working as designed.

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