Bug 1474992 - Failed VMs are not rolling back end-to-end
Summary: Failed VMs are not rolling back end-to-end
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Red Hat CloudForms Management Engine
Classification: Red Hat
Component: Automate
Version: 5.6.0
Hardware: Unspecified
OS: Unspecified
high
high
Target Milestone: GA
: cfme-future
Assignee: Tina Fitzgerald
QA Contact: Dave Johnson
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2017-07-25 19:17 UTC by Saif Ali
Modified: 2021-09-09 12:27 UTC (History)
6 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2017-09-27 14:00:53 UTC
Category: ---
Cloudforms Team: CFME Core
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)

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


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