Skip to content

Deprecate terminationGracePeriodSeconds in favour of cleanup_grace_period_seconds and pod_termination_grace_period_seconds

In !2130 (merged) we added the functionality to allow for pod termination and pod cleanup grace periods to be specified.

We should deprecate terminationGracePeriodSeconds in favour of cleanup_grace_period_seconds and pod_termination_grace_period_seconds. In addition, adding these fields introduces a need to manually handle behavior changes as to preserve backwards compatibility:

With the new changes, if we don't specify any termination period, we'll have the values nil, 0, 0. So for both, GetCleanupGracePeriodSeconds and GetPodTerminationGracePeriodSeconds, TerminationGracePeriodSeconds will be nil so the value of zero will be specified. For PodTerminationGracePeriodSeconds the behavior will stay the same, we will pass the value of zero, however for CleanupGracePeriodSeconds the behavior will be different. As per the API docs, the value zero means delete immediately while before, we used to set the value to be nil since we didn't use it, which would fall back to using the grace period specified for the Pod. I confirmed that this is the case on main, this is the value by default in the final deployed Pod terminationGracePeriodSeconds: 0.

It seems to me that the best compromise we can have right now is:

  • Convert all grace periods to pointers
  • Have checks to ensure that the default value of CleanupGracePeriodSeconds is zero, when not configured
  • Allow PodTerminationGracePeriodSeconds to be nil so that its default behavior can be utilized, which falls back to the configured CleanupGracePeriodSeconds
  • In the deprecation issue, remove the old TerminationGracePeriodSeconds field and allow both CleanupGracePeriodSeconds and PodTerminationGracePeriodSeconds to be nil by default so that their default behaviors can be invoked.