Ansible Operator Finalizers

Finalizers allow controllers (such as an Ansible Operator) to implement asynchronous pre-delete hooks. This allows custom logic to run after a resource has been marked for deletion, but before the resource has actually been deleted from the Kubernetes cluster. For Ansible Operator, this hook takes the form of an Ansible playbook or role. You can define the mapping from your finalizer to a playbook or role by simply setting the field on the entry in your watches.yaml. You can also choose to re-run your top-level playbook or role with different variables set. The watches.yaml finalizer configuration accepts the following options:

See Ansible watches documentation for more information.

name

name is required.

This is the name of the finalizer. This is basically an arbitrary string, the existence of any finalizer string on a resource will prevent that resource from being deleted until the finalizer is removed. Ansible Operator will remove this string from the list of finalizers on successful execution of the specified role or playbook. A typical finalizer will be <qualified-group>/finalizer, where <qualified-group> is the fully qualified group of the resource being managed.

playbook

One of playbook, role, or vars must be provided. If playbook is not provided, it will default to the playbook specified at the top level of the watches.yaml entry.

role

One of playbook, role, or vars must be provided. If role is not provided, it will default to the role specified at the top level of the [watches.yaml][watches] entry.

This field is identical to the top-level role field.

vars

One of playbook, role, or vars must be provided.

vars is an arbitrary map of key-value pairs. The contents of vars will be passed as to the playbook or role specified in the finalizer block, or at the top-level if neither playbook or role was set for the finalizer.

Here are a few examples of watches.yaml files that specify a finalizer:

---
- version: v1alpha1
  group: app.example.com
  role: database
  finalizer:
    name: app.example.com/finalizer
    vars:
      state: absent

This example is nearly identical to the first, except it will run the /opt/ansible/roles/database role, rather than a playbook, with the state variable set to absent.

This example will run the /opt/ansible/roles/teardown_database role when the Custom Resource is deleted.

---
- version: v1alpha1
  kind: Database
  playbook: playbook.yml
  finalizer:
    playbook: destroy.yml

This example will run the /opt/ansible/destroy.yml playbook when the Custom Resource is deleted.

This example will run the myRole when the Custom Resource is deleted. (The collection must have been installed.)

You can set playbook or role and vars at the same time. This can be useful if only a small part of your logic handles interacting with the component that requires cleanup. Rather than run all the logic again, you can specify only to run the role or playbook that handled the interaction, with a different variable set.

---
- version: v1alpha1
  group: app.example.com
  kind: Database
  playbook: playbook.yml
  finalizer:
    name: app.example.com/finalizer
    role: manage_credentials
    vars:
      state: revoked