VM Retirement with Custom Automation

We are looking to implement vm retirement in different phases.

  • Send notification emails about upcoming retirement
  • Power off the VM
  • Fully retire VM using custom automation after 2 weeks

By deafult VM is powered off by setting vm.retires_on attribute. Is there a way to trigger custom automation, two weeks after powering off the VM. I can use ‘VM Retired’ event to trigger the action, but how can I delay it for two weeks. Is there any condition that I can use?

Thanks in advance!!


@ramrexx can you help out here? i believe you have some good examples of how to do this.

1 Like

You could modify the retirement state machine step “PreRetirement” to have a method that sets a the retry to 2 weeks on first run. Or better yet have the method check daily for a tag on the VM. For example, a VM would not be decommissioned unless it was tagged.

For reference @pemcg has a nice write up of how retirement methods can be used here: https://pemcg.gitbooks.io/mastering-automation-in-cloudforms-4-2-and-manage/content/vm_instance_retirement/chapter.html.

Thanks for your help.

We are able to make VM Retirement to work with different phases by tagging and resetting retirement date.

Could you elaborate a bit more on how you solved this?
I am looking into ways to do a similar thing and would appreciate hearing more about your approach.

We assigned VM(s) with tag(soft_retire), retirement date and retirement warn(14) while deploying.

Warning emails:
In first step when vm_retire_warn event is triggered 14 days before vm retires , we are sending out email and resetting retirement warn days. Please refer below link for warning emails.

Similarly, when request_vm_retire event is triggered, based on tag(soft_retire) we are unassgning tag(soft_retire) and assigning tag(full_retire), resetting retirement date and powering off the vm. So, next time when it is triggered based on tag(full_retire) we are removing the vm completely.

Hope this helps, let me know if you have any questions.

On the retirement tagging:
That makes sense to me. I am curious where are you injecting your custom logic.
Are you using a control policy/event, or a state early in the retirement state machine like StartRetirement?

We are not using Control Policy/Events, doing it in the same as warning emails. Copying code from ManageIQ domain to local domain and customizing it.

Here’s the code that worked for me. I copied and modified the start_retirement.rb method.
Added a soft_retire_days attribute to the instance.


if vm.retiring?
  $evm.log(:error, 'VM is in the process of being retired. Aborting current State Machine.')
  exit MIQ_ABORT

unless vm.tagged_with?('lifecycle', 'retire_full')
  ext_days = $evm.object['soft_retire_days']
  $evm.log(:info, 'VM not tagged for full retirement.')
  $evm.log(:info, "VM will power off for #{ext_days} days before retiring fully.")
  # power off VM if not already
  vm.stop unless vm.nil? || vm.attributes['power_state'] == 'off'

  # tag full_retire
  $evm.log(:info, 'VM Tagged with lifecycle/retire_full')

  # update retire date
  new_date = Time.now + ext_days.days
  vm.retires_on = new_date.to_s
  $evm.log(:info, "New full-retirement date: #{vm.retires_on}")

  # send email
  $evm.log(:info, 'Aborting current State Machine.')
  exit MIQ_ABORT

$evm.log(:info, "VM before start_retirement: #{vm.inspect} ")

1 Like

Did the code actually worked in production inside start_retirement.rb?

MIQ_ABORT will raise an error:

State= running raised exception:

And that error will break things with

In State=[StartRetirement], invoking [on_error] method=[update_retirement_status(status => ‘Error Starting Retirement’)]

And that is the end of the workflow.

We split the suggested code in a separate instance before the start_retirement.

In that step we do not create any status_update message.

The error is trapped and we have delayed retirement working.