Bug 1740285

Summary:	It's possible to do power operations on VMs of paused provider, it gets queued and never executed
Product:	Red Hat CloudForms Management Engine	Reporter:	Angelina Vasileva <anikifor>
Component:	Providers	Assignee:	Martin Slemr <mslemr>
Status:	POST ---	QA Contact:	PJ Richardson <prichard>
Severity:	medium	Docs Contact:	Red Hat CloudForms Documentation <cloudforms-docs>
Priority:	medium
Version:	5.11.0	CC:	jhardy, mshriver
Target Milestone:	GA
Target Release:	5.11.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:		Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	Bug
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	CFME Core	Target Upstream Version:
Embargoed:

Description Angelina Vasileva 2019-08-12 14:57:22 UTC

Description of problem:
It's possible to do power operations on VMs of paused provider, it gets queued and never executed

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

How reproducible:
Always

Steps to Reproduce:
1. Pause a provider (RHV)
2. Navigate to its VMs and power one VM on
3. Go to tasks: Task has been queued
4. Resume the provider, wait for the refresh to finish
5. Go to tasks again, it will be in "Queued" state forever.

Actual results:
The task is queued forever (at least 20 min after the provider was resumed and I was able to execute the same task and it was completed successfully, but the original one still queued).

Expected results:
I'd expect power operations to be disabled on paused provider in the first place. If it's possible to queue them, then it should be resumed when provider is resumed.

Additional info:

Comment 2 Adam Grare 2019-08-12 15:49:30 UTC

Hey Martin I thought we were supposed to be dropping queue messages to the maintenance zone, can you take a look?

Comment 3 Martin Slemr 2019-08-19 11:24:24 UTC

Hi Adam, 

We decided that RFE for suspending provider were just about moving provider to Maintenance zone (to solve issue with big logs when remote endpoint was unavailable). 

All other features regarding suspending was planned as "Phase 2". Both backend and frontend part. 
So should I start Phase 2? Do I need some RFE?

Answer to your question is, that task isn't put to MiqQueue (MiqQueue.put checks for maintenance zone) but MiqTask is created

Comment 4 Adam Grare 2019-08-19 14:10:21 UTC

So without phase 2 it was found that this feature was way too confusing to users and we'll likely disable it for this release until it is more complete.  I wouldn't start it yet until we get further into feature planning for 5.1.

Comment 5 Adam Grare 2019-08-19 14:11:19 UTC

For this specifically, I think moving the task to an error if no queue item was created would satisfy this BZ

Comment 6 CFME Bot 2019-08-20 13:26:32 UTC

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

Comment 7 CFME Bot 2019-08-28 15:50:55 UTC

New commit detected on ManageIQ/manageiq/master:

https://github.com/ManageIQ/manageiq/commit/8c161a423bf633e523f19e4716d5ae07620cd703
commit 8c161a423bf633e523f19e4716d5ae07620cd703
Author:     Martin Slemr <mslemr>
AuthorDate: Tue Aug 20 09:14:33 2019 -0400
Commit:     Martin Slemr <mslemr>
CommitDate: Tue Aug 20 09:14:33 2019 -0400

    Finish VM Task to error state when EMS paused

    For example Power on/off operations.

    Fixes https://bugzilla.redhat.com/show_bug.cgi?id=1740285

 app/models/mixins/process_tasks_mixin.rb | 7 +-
 spec/models/mixins/process_tasks_mixin_spec.rb | 27 +
 spec/models/vm_spec.rb | 2 +
 3 files changed, 35 insertions(+), 1 deletion(-)