Feature Overview (aka. Goal Summary)  

Some users have experienced data loss when using Delete retain policy and reverted to a safer Retain policy. With Retain policy all volumes that are retained and left unclaimed have their phase is set to Released. As the released volumes pile up over time admins want to perform manual cleanup based on the time when the volume was last used, which is when the volume transitioned to Released phase.

The goal of this feature is to provide a way to check when a PV was released. This allows customers to define a policy for PVs that have been released after a given time and perform an action for example delete or archive them.{_}

We will introduce a new status field in PersistentVolumes that contains the timestamp of the last PV status phase.

Goals (aka. expected user outcomes)

1. Introduce a new status field in PersistentVolumes.
2. Update the new field with a timestamp every time a volume transitions to a different phase (pv.Status.Phase).
3. Allow admins to list PVs based on their last transition time.

This field will not only track the release transition time but all PV status phases changes. This introduce an interesting side use case, for example measure time between a PV Pending and Bound status.

Requirements (aka. Acceptance Criteria):

KEP is accepted upstream and feature is now beta, this Jira feature tracks upstream work to promote it GA and full support in OCP.

• Feature implemented behind a feature flag
• Unit tests completed and enabled
• Add unit tests covering feature enablement/disablement.
• Initial e2e tests completed and enabled
• Allowing time for feedback (at least 2 releases between beta and GA).
• Manually test version skew between the API server and KCM. See the expected behavior below in Version Skew Strategy.
• Manually test upgrade->downgrade->upgrade path.

Use Cases (Optional):

Story 1

As a cluster admin I want to use Retain policy for released volumes, which is safer than Delete, and implement a reliable policy to delete volumes that are Released for more than X days.

https://github.com/kubernetes/enhancements/blob/master/keps/sig-storage/3762-persistent-volume-last-phase-transition-time/README.md#story-2Story 2

As a cluster admin I want to be able to reason about volume deletion, or produce alerts, based on a volume being in Pending phase for more than X hours.

Questions to Answer (Optional):

Include a list of refinement / architectural questions that may need to be answered before coding can begin.  Initial completion during Refinement status.

Out of Scope

1. Implement any form of volume health monitoring.
2. Kubernetes will take any new actions based on the added timestamps in PersistentVolume.

Customer Considerations

This feature is limited to a read only additional helpful information that can help admin define policies or alerts.

Documentation Considerations

Release notes only

Interoperability Considerations

None at the moment but we can imagine other components could benefit from it.