Introduce a reclaim policy for ephemerally created Volume resources

[balpert89]

Summary

When creating a Machine resource there is the possibility to create the resource with an ephemerally managed Volume resource. The resulting Volume will show an ownerReference entry pointing to the created Machine resource, as well as blockOwnerDeletion set to true.

In case the Machine has to be recreated, there is currently no possibility to prevent deletion of the ephemerally managed Volume resource. This shortcoming should be tackled with the introduction of a Reclaim Policy similar to Kubernetes Reclaim Policies for Persistent Volumes.

The Reclaim Policy should support 2 modes:

• Retain: the resource is not deleted after the managing resource has been deleted
• Delete: the current behavior, the resource is garbage-collected when the managing resource has been deleted

To not break current behavior the Reclaim Policy should be defaulted to Retain if not set.

Basic example

apiVersion: compute.ironcore.dev/v1alpha1
kind: Machine
metadata:
  name: machine
spec:
  volumes:
  - device: oda
    ephemeral:
      volumeTemplate:
        metadata:
          creationTimestamp: null
        spec:
          reclaimPolicy: Retain # this is the new field defining the "Retain" strategy for the corresponding volume resource
          image: my-image:tag
          resources:
            storage: 10Gi
          volumeClassRef:
            name: fast
          volumePoolRef:
            name: pool
    name: root-disk-1

This instructs the controller to not remove the Volume resource. When the managing Machine resource is deleted, the OwnerReference as well as the .spec.claimRef should be cleared.

Open questions

• should the controller label the Volume resource after deletion of the managing resource as such it is no longer ephemerally managed?

Motivation

This proposed feature would make it possible to safeguard for potential data loss in case the owning Machine resource needs to be recreated, independent of the reason (failure, config change, ...).