Align with KEB team how we indicate in RuntimeCR a delete request for a cluster and what kind of deletion-policy should be used

[tobiscr]

Description

As preparation of the safe deletion of Kyma runtimes, we have to agree on the technical approach how we indicate that a cluster should be disposed.

Proposal:

• establish deletion-timestamp field:
  • A common pattern in Kuberentes is to set a deletion-timestamp field for resources, which should be removed (e.g. Pods): as soon as this field is set, the Kyma runtime will be disposed by KIM
  • The timestamp can also be used to calculate the remaining retention time of the runtime until it will be finally deleted.
• define another field containing the deletion policy
  • Related to the requirement to be able to interrupt the final deletion, we could introduce a deletion policy field which defines how the cluster will be removed (e.g. default value is deleteWithRetention but also the option deleteNever or deleteImmediatelly could be supported).

AC:

• Agree within Framefrogs on the technical approach how disposing (deleting) requests are indicated within the RuntimeCR
  • The solution has to consider an option for measuring the time elapsed since the deletion request was requested to be able to calculate the retention time
  • We want to support options to suspend / immediately execute the final deletion of a cluster: discuss and agree how we track the used deletion approach (e..g by offering an option to define a kind of deletion strategy).
• Share the agreement with Gophers. Consolidate the proposal with them and come to a final agreements.
  • Document the agreement in an ADR.

Reasons

Establish architectural agreement between Gophers and Framefrogs for the " safe deletion" feature.

Attachments

[tobiscr]

Closing it as we detected several technical disadvantages when using hibernation for preventing unintended cluster deletion. Focusing now on #642 .