Bug 1614086

Summary: Unable to delete exisiting service provision request via kill_provision.rb tool script.
Product: Red Hat CloudForms Management Engine Reporter: Neha Chugh <nchugh>
Component: ProvisioningAssignee: William Fitzgerald <wfitzger>
Status: CLOSED NOTABUG QA Contact: Sudhir Mallamprabhakara <smallamp>
Severity: high Docs Contact:
Priority: unspecified    
Version: 5.9.0CC: abellott, dmetzger, jhardy, jocarter, jrafanie, mkanoor, mshriver, nchugh, obarenbo, smallamp, tfitzger, yrudman
Target Milestone: GA   
Target Release: 5.10.z   
Hardware: All   
OS: All   
Whiteboard:
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2019-04-30 19:12:40 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: CFME Core Target Upstream Version:
Embargoed:

Description Neha Chugh 2018-08-09 01:50:54 UTC
Description of problem:
Unable to delete exisiting service provision request via kill_provision.rb tool script.

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

How reproducible:
Always

Steps to Reproduce:
1. There are lots of existing provisioning requests generated by ordering service catalog which eventually slower the cloudforms' appliance
2. kill_provision.rb tool script used with service provision request# doesn't kill the provisioning process.
3.  It gives below message after execution:

root@test229 tools]# ./kill_provision.rb  99000000000052
Checking for provisions IDs:<[99000000000052]>
Successfully processed <0> of <1> in 0.012257736 seconds.

Here 99000000000052 is the  service_template_provision_task_99000000000052

Actual results:
It doesn't process with task id.



Expected results:
It should kill the provisioning process of this task id.

Additional info:

Comment 4 Joe Rafaniello 2018-08-10 12:55:34 UTC
Looking at the script, it looks like it will try to stop existing multi-step provisioning tasks from moving onto the next stop but I don't know if it will stop a provisioning that is currently running on the external provider.

Reassigning to a team more familiar with the provisioning process since this script's logic hasn't been changed recently so we might not be killing all the relevant queue messages and tasks properly.

Comment 5 Sudhir Mallamprabhakara 2018-11-20 19:24:56 UTC
Can you please check on 5.10 and let us know if this is still broken?

Thanks
- Sudhir

Comment 7 Mike Shriver 2019-10-30 16:10:35 UTC
This was closed without any associated code changes, moving to NOTABUG