Bug 1326955

Summary:	VM start / stop operations via the REST sits in queued state if no Provider operations role is active
Product:	Red Hat CloudForms Management Engine	Reporter:	Jared Deubel <jdeubel>
Component:	API	Assignee:	abellott
Status:	CLOSED ERRATA	QA Contact:	Martin Kourim <mkourim>
Severity:	medium	Docs Contact:
Priority:	medium
Version:	5.4.0	CC:	abellott, dajohnso, jhardy, mfeifer, obarenbo, simaishi
Target Milestone:	GA
Target Release:	5.6.0
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:	vm:power:rest
Fixed In Version:	5.6.0.5	Doc Type:	Bug Fix
Doc Text:	When queueing virtual machine power or SmartState operations through the REST API, the zone was not specified for the queue. As a result, in environments with providers in different zones, those providers were not receiving the task to perform on the virtual machines. This caused virtual machine start and stop operations to remain in a queued state. This has been fixed in this update and the issue no longer occurs.	Story Points:	---
Clone Of:		Environment:
Last Closed:	2016-06-29 15:49:10 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 Jared Deubel 2016-04-13 22:11:28 UTC

Description of problem:
Issue with submitting VM start / stop operations via the REST API.  The code works against a single zone region, but when used in a multi zone region the task is queued and never runs.  In the environment here, the UI appliances have Web Services on and not provider operations.  The UI appliances do not have network access to the providers in all cases and so the worker appliances must be used for provider operations.

We ran some tests to diagnose the issue.  Enabling Web Services on a worker appliance allows the API call to work.

I was able to reproduce the issue using my home lab running fully up to date 5.4 and 5.5 appliances and a pair of vCenter 5.5 appliances.  If network access is present, submitting the API call to either worker works regardless of which provider the VM is on.  Submitting to the UI appliance without Provider Operations yielded the same result of a task queued indefinitely.


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

How reproducible:
Very

Steps to Reproduce:
1. API call to any appliance that doesn't have the operations role

Comment 2 CFME Bot 2016-04-25 18:26:19 UTC

https://github.com/ManageIQ/manageiq/pull/8225

Comment 3 CFME Bot 2016-04-25 22:01:09 UTC

New commit detected on ManageIQ/manageiq/master:
https://github.com/ManageIQ/manageiq/commit/7b76cc442e18fcaf836bfef3b8debcfbb76202a6

commit 7b76cc442e18fcaf836bfef3b8debcfbb76202a6
Author:     Alberto Bellotti <abellott>
AuthorDate: Mon Apr 25 14:12:52 2016 -0400
Commit:     Alberto Bellotti <abellott>
CommitDate: Mon Apr 25 14:12:52 2016 -0400

    [api] VM power operations are not queued properly
    
    When queueing VM power or smartstate operations, the zone was not getting
    specified for the queue so in environments with providers in different zones,
    those providers were not getting the task to perform on those VMs.
    
    This fixes: #7998
    
    https://bugzilla.redhat.com/show_bug.cgi?id=1326955

 app/controllers/api_controller/action.rb |  2 ++
 spec/requests/api/vms_spec.rb            | 13 +++++++++++++
 2 files changed, 15 insertions(+)

Comment 7 CFME Bot 2016-05-17 17:19:19 UTC

https://github.com/ManageIQ/manageiq/pull/8473

Comment 8 Taras Lehinevych 2016-05-20 17:14:06 UTC

Verified in 5.6.0.7-beta2.6

Comment 10 errata-xmlrpc 2016-06-29 15:49:10 UTC

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHBA-2016:1348