+++ 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:
[/Customer/Intuit/Retirement/StateMachines/VMRetirementLocal/Default]

This state machine has a state called "DeleteFromProvider" that calls a factory instance to delete a vm:
[/ManageIQ/Infrastructure/VM/Retirement/StateMachines/Methods/RemoveFromProvider]

OnEntry of the state "DeleteFromProvider", a special method to dump root is run:
[/Customer/Intuit/Retirement/StateMachines/VMRetirementLocal/update_retirement_status]

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


How reproducible:


Steps to Reproduce:
1.
2.
3.

Actual results:


Expected results:


Additional info: