Retirement As A Request

Retirement as a request (RaaR) was added in the Hammer release and replaces retire_now as the default retirement method. The retire_now method was left intact for backward compatibility and can ONLY be used with a pre-Hammer Automate state machine.

Note - Retirement as a request and retire_now are available for all of the “retireable” objects.


Let’s look at the old retire_now retirement processing first.

We’ll use the Service object in the following example.

In pre-Hammer releases, the retire_now method is called when retiring an object through the UI and/or scheduled retirements. The method raises a request_service_retire event and resolves the instance shown below:

As you can see, the request_service_retire instance contains relationships to:

  1. (rel1) Enforce policy.
  2. (rel2) Check Prevent Policy.
  3. (rel3) Get the retirement entry point.
  4. (rel4) Retire the Service with the entry point returned from #3 above.

Since the instance controls what happens when retire_now is called on a Service object, it can be easily modified.

Retirement As A Request

Now, let’s look at the retirement as a request (RaaR) processing for the Service object.

In the Hammer release, the make_retire_request method is called when retiring an object through the UI and/or scheduled retirements, and has a very different workflow.

RaaR uses MiqRequests/MiqRequestTasks much the same way they’re used in provisioning. A MiqRequest (ServiceRetireRequest) is created when retirement is called with make_retire_request.

The Retire Request processing:

  1. Service Retire Request is created.
  2. Service Retire Request is approved.*
  3. Once approved, a request task is created for every “retireable” service resource.
  4. All Request Tasks are sent to Automate for processing.
  5. Service Retire Request are “finished” once all of its tasks have completed (with or without error).

*Retire Approval - The default behavior is to approve the request. Once the request has been approved, the retire tasks are created and retirement processing begins.

Important Note - Retirement is usually highly customized, so you’ll likely want to add some logic to your retirement approval state machine methods.

The retire_request is created when:

  1. A user initiates retirement through the UI. (Select object, lifecycle -> retire now)
  2. The scheduled retirement check encounters an object(s) where the retires_on date is in the past.

The retirement approval state machine is where custom logic would be added to change the default behavior.

The first decision is what to do with the object ready to be retired.

To retire the object:

  1. Approve the request.

To extend/remove from retirement:

  1. Modify the objects retire_on value. (Extend or remove the retires_on value)
  2. Deny the request.

The Service object was used in the above examples. The following example shows one way to handle retirement approval for Infrastructure VMs. The same idea can be used in the Service retirement approval state machine. The code sample came from a consultant who was implementing retirement approval changes. We modified the code for this example.

The screen shot above shows the first part of the example approval state machine with the validate_request method. If a custom attribute “Queued for removal” exists, a log message is issued. If not, the custom attribute is created AND the retirement date is extended 2 weeks into the future.

The screen shot above shows the second part of the example approval state machine with the approve_request method.

The request will be approved if:

  1. approval_type == auto
  2. retires_on < now AND the custom attribute exists
    Otherwise, the request will be denied.

If the request is approved, the object(s) will be retired.

***The most important thing to remember is that the request only facilitates retirement. The object retires_on date will have to be modified to stop new requests from being created for that object.

Note - The code snippets included here are only meant to be examples.

Adjust the Scheduled Retirement Check Interval

The advanced settings contain settings for the time interval to check retirement for each object type.

Default values:
:orchestration_stack_retired_interval: 10.minutes:
:service_retired_interval: 10.minutes:
:vm_retired_interval: 10.minutes:

These settings can be adjusted for each object type which will affect how often retirement requests are created.

1 Like

Many thanks Tina!