The recent VM Retirement enhancements could cause issues with existing customers using the old style automate model who wish to use the old style retirement statemachine. The following directions are intended to resolve this issue. Backward Compatibility: With the exception of policy, modifications to the automate model would make it possible to use the old style retirement state machine: The previous VM retirement functionality: * Set the VM retired flag * Set the VM retire_date value * Stopped a running VM * Called into the retirement state machine Because a major feature of the new retirement is that it exposes the functionality to automate, backward compatibility can be achieved by adding an automate method to the customers existing state machine that would accomplish the tasks previously done in code. This same functionality can be attained by the following: Modify the state machine to use the old retirement state machine For the following directions, the domain references of “CUSTOMER” means the customer domain containing the old automate model which has a higher priority than the ManageIQ shipped domain. 1. Add new event instance, “request_vm_retire” event to /system/event class in the CUSTOMER domain. a. Set logical event to “vm_retired” b. Set rel5 value to point to the same value that is set in the /system/event/vm_retired rel5 relationship in the CUSTOMER domain *Note - value is most likely to be: /Automation/VMLifecycle/Retirement?vm_id=${process#vm_id} 2. Change schema for CUSTOMER domain: /Factory/StateMachines/VMRetirement class to add a new entry name: preretirement type: state datatype: string subst flag = true message: create on_entry: update_retirement_status(status => ’Starting preretirement’) on_exit: update_retirement_status(status => ‘Ended preretirement’) on_error: update_retirement_status(status => 'Error in preretirement’) 3. Change the schema sequence, if necessary. The new preretirement state should be the first state in the state machine. 4. Change /Factory/StateMachines/VMRetirement/Default instance: add preretirement value of: /Factory/VM/Preretirement 5. Add instance: /Factory/VM/Preretirement set execute attribute value to: preretirement 6. Add method: /Factory/VM/preretirement with the following content: vm = $evm.root[‘vm’] vm.finish_retirement if vm Note* It appears backwards that we're calling the finish_retirement method in the preretirement method. The reason for this is that the previous retirement process immediately set the retired flag and retired_on date. The enhanced retirement process waits until the retirement is finished before it sets the retired and retires_on attributes. By using the finish_retirement method, we reverting back to the old behavior so that the customers existing retirement state machine can proceed as before.
Tina, how to test this? Do I need an older appliance and "upgrade" it? /Automation and /Factory don't exist any more. How should I proceed?
Hi Pete, Yes, can you perform the upgrade from an older appliance? That should give you the CUSTOMER domain with the /Factory and /Automation namespaces. Let me know if you have any questions. Thanks, Tina
Hi Dave, Can you have someone test this? Thanks, Tina
Hi Jan, Thanks so much for the feedback! 1. Yes, the older methods expect the additional argument. The status_state does need to be supplied. 2. The log is confusing for this one. The preretirement method call to vm.finish_retirement should have set the retired flag to true and the builtin policy should have powered off the VM. Do you see any errors and/or "Finishing Retirement for" the vmname in the evm.log? If it's easier, you can send me the credentials for the appliance and I'll check it out. Thanks, Tina
Hi Jan, The builtin policy to stop a newly retired VM should have kicked in, but I can see from your logs that it hasn't. I think it makes sense to power it off in our preretirement method, so lets change step 6 to read: 6. Add method: /Factory/VM/preretirement with the following content: vm = $evm.root[‘vm’] if vm vm.finish_retirement if vm.power_state == "on" $evm.log("info", "Preretirement powering off VM") vm.stop end end Thanks, Tina
Tina, yup - changing the preretirement automate method to stop the VM fixed the issue. Works for me now.
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHSA-2015:2551