Bug 1474992

Summary:	Failed VMs are not rolling back end-to-end
Product:	Red Hat CloudForms Management Engine	Reporter:	Saif Ali <saali>
Component:	Automate	Assignee:	Tina Fitzgerald <tfitzger>
Status:	CLOSED NOTABUG	QA Contact:	Dave Johnson <dajohnso>
Severity:	high	Docs Contact:
Priority:	high
Version:	5.6.0	CC:	jhardy, mkanoor, myoder, obarenbo, saali, tfitzger
Target Milestone:	GA
Target Release:	cfme-future
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:		Doc Type:	If docs needed, set a value
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2017-09-27 14:00:53 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 Saif Ali 2017-07-25 19:17:02 UTC

Description of problem:
Cloudforms is not rolling back the VM end-to-end. Particularly, it’s not deleting it from vCenter & VMDB.


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


How reproducible:


Steps to Reproduce:
1.
2.
3.

Actual results:


Expected results:


Additional info:

Comment 3 Greg McCullough 2017-07-26 15:42:57 UTC

VMs created outside of the ManageIQ Lifecycle provisioning will not have the MIQ GUID property nor will they have a "miq_provision" which is what we check in the default remove_from_provider method in automate.

https://github.com/ManageIQ/manageiq/blob/darga-5/db/fixtures/ae_datastore/ManageIQ/Infrastructure/VM/Retirement/StateMachines/Methods.class/__methods__/remove_from_provider.rb#L17

My guess is that the VM is not really being created through the ManageIQ provisioning task.  

Can you describe how the VM is being provisioned as well as what is being used to verify that the VM was provisioned by a ManageIQ provision task?

As the above method shows you can also create the tag "lifecycle/retire_full" and apply that to the VM to have it removed from the provider.

Comment 10 Greg McCullough 2017-08-14 17:36:34 UTC

The screenshots are showing that we are passing the expected VM notes value to VMware during provisioning.

Was the customer able to confirm that the VM was created with that note?  Also, is there any other process that might be updating/replacing the notes on a VM within their VMware environment.

Can they track a VM that we have provisioned and compare the notes we pass (based on the provision logging) and what is on the VM when the process fails?

I would also highly suggest reviewing the last comment in https://bugzilla.redhat.com/show_bug.cgi?id=1474992#c6 and possibly changing their process to use the miq_provision relationship instead of the notes value.

Comment 12 Tina Fitzgerald 2017-09-26 21:01:17 UTC

Hi Saif,

Can we close this ticket?  There hasn't been any customer response in over a month.

Thanks,
Tina