Red Hat Bugzilla – Bug 1300738
remove_from_provider method does not delete from provider for VMs not provisioned by CF version 3.2
Last modified: 2016-01-22 12:47:55 EST
+++ This bug was initially created as a clone of Bug #1300720 +++
Description of problem:
We noticed an error during retirement and would like some support on it.
This is a production issue.
We are using Cloudforms 3.2 and we have a retirement state machine:
This state machine has a state called "DeleteFromProvider" that calls a factory instance to delete a vm:
OnEntry of the state "DeleteFromProvider", a special method to dump root is run:
We find that the logs show a VM exists:
[----] I, [2016-01-19T18:51:07.597732 #32632:883239c] INFO -- : Q-task_id([automation_task_702000000008929]) <AEMethod update_retirement_status> update_retirement_status - Root:<$evm.root> Attribute - vm_id: 702000000004926
[----] I, [2016-01-19T18:51:07.596606 #32632:883239c] INFO -- : Q-task_id([automation_task_702000000008929]) <AEMethod update_retirement_status> update_retirement_status - Root:<$evm.root> Attribute - vm: pprdqbows40a.ie.intuit.net
In the factory method "remove_from_provider", if vm is not nil AND (vm has miq_provision OR tagged with lifecycle/retire_full), then it should retire.
But it does not retire. The (lack of) log statements show that it never enters this block.
Further investigation showed that it looks like VM objects created in CF3.0 do not have a miq_provision reference while VM objects created in CF3.2 do have a miq_provision reference.
Should 3.0 original objects have been given a "dummy" reference? Should old objects be tagged with lifecyle/retire_full manually?
Version-Release number of selected component (if applicable): 5.4
Steps to Reproduce:
*** This bug has been marked as a duplicate of bug 1300559 ***