Bug 1599299 - [REGRESSION] Cannot retire service via SSUI, Error delivering event to Automate
Summary: [REGRESSION] Cannot retire service via SSUI, Error delivering event to Automate
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Red Hat CloudForms Management Engine
Classification: Red Hat
Component: UI - Service
Version: 5.10.0
Hardware: Unspecified
OS: Unspecified
high
high
Target Milestone: GA
: 5.10.0
Assignee: drew uhlmann
QA Contact: Antonin Pagac
URL:
Whiteboard:
Depends On:
Blocks: 1535229
TreeView+ depends on / blocked
 
Reported: 2018-07-09 12:51 UTC by Antonin Pagac
Modified: 2019-02-11 13:58 UTC (History)
9 users (show)

Fixed In Version: 5.10.0.5
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2019-02-11 13:58:42 UTC
Category: ---
Cloudforms Team: ---
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)
evm.log snippet (4.16 KB, text/plain)
2018-07-09 12:51 UTC, Antonin Pagac
no flags Details

Description Antonin Pagac 2018-07-09 12:51:38 UTC
Created attachment 1457447 [details]
evm.log snippet

Description of problem:
Can't retire a service in SSUI. It seems there's an error delivering the event to Automate. It made 101 retries before throwing an error to evm.log. Error is not propagated to the UI.
I can retire a VM via OPS UI with no problem, the issue seems to be around retiring a service via SSUI.
For the last relevant message in evm.log, see attached snippet.
Marked as regression because this works in 5.9.3.4.

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

How reproducible:
Time-consuming, need to wait for 100 retries to see an error
Reproduced once, probably 100% reproducible 

Steps to Reproduce:
1. Create new Dialog, create new Service Catalog Item with VM provisioning on VMWare, order it
2. In SSUI, select the ordered service and choose Retire
3. See messages in evm.log

Actual results:
Nothing happens in SSUI, service not retired, still running VM; no error in SSUI, error in evm.log after 100 retries

Expected results:
Service retired

Additional info:
Tried with a service that provisions a VM on vsphere 6. The same configuration works on 5.9.3.4 with no problems.

Comment 3 Tina Fitzgerald 2018-07-09 17:46:16 UTC
Hi Chris,

The Classic UI was changed to make a request instead of calling retire_now.

Could you change the Service UI to call the new request code?
https://github.com/ManageIQ/manageiq-ui-classic/pull/3409

Thanks,
Tina

Comment 6 Tina Fitzgerald 2018-07-10 21:07:06 UTC
Hi Chris,

Here is the PR DrewU made for the new retirement API call:
https://github.com/ManageIQ/manageiq-api/pull/380

Let me know if you have any questions.

Thanks,
Tina

Comment 9 Antonin Pagac 2018-07-16 15:13:46 UTC
Appliance version: 5.10.0.4

This does not appear to be fixed. Service isn't retiring after 23 tries. In 5.9.x, service retired almost immediately.

Comment 10 drew uhlmann 2018-07-17 11:43:18 UTC
Hey Antonin! That service retired just fine on the appliance you provided when I tried retiring it through the SUI.

Comment 11 drew uhlmann 2018-07-17 11:44:19 UTC
Due to the fact that we're now using a request to retire the service it may be slower than it was on 5.9. That's expected behavior and not a bug.

Comment 12 drew uhlmann 2018-07-17 12:05:21 UTC
It'd be nice to have this ticket updated with the exact retirement path you're using because we have two, and it's not super-helpful to say "In SSUI, select the ordered service and choose Retire". Can you please update with the type of retirement this ticket is about?

Comment 13 Antonin Pagac 2018-07-17 12:16:11 UTC
It indeed works if I choose to retire the service from its details:
1. Navigate to My Services
2. Click on the service to see its Properties, Resources, etc
3. Choose Lifecycle -> Retire

It does not work however if I choose to retire the service from service list:
1. Navigate to My Services
2. At the list of all services, click on the menu button of chosen service and choose Retire

I was not aware of this when I was creating the BZ.

Comment 14 drew uhlmann 2018-07-17 12:19:25 UTC
Thanks! You're right, I need to update that call as well. PRs incoming.

Comment 16 Antonin Pagac 2018-07-30 14:34:38 UTC
Verified with 5.10.0.6.


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