kubernetes/kubernetes#39657
kubernetes/kubernetes#44172

/cc @skriss

@jingxu97 I think we're going to have something in alpha for 1.7, can we can we please set the milestone to 1.7?

@kubernetes/sig-storage-feature-requests could someone please update the issue description to the new template. Thanks!

Is this based on the proposal here: https://github.com/kubernetes/community/blob/master/contributors/design-proposals/volume-snapshotting.md ?

@jingxu97 thanks! I can't access it but I just requested access.

@jingxu97 I wanted to add an important note here regarding overall approach. I'm not this is the right place to put this, but I would be a happy to be guided to the right forum to bring this up.

Coming from a long background in oVirt and OSP I feel there is an important aspect that needs to be discuss which is ownership of the state of snapshots (and overall volume metadata) and discoverablility of the this metadata.

In cloud and on premise users (developers and admins) might prefer the native storage APIs over the Kube APIs. Kube is also not the one creating the snapshot, it is the cloud service or the storage itself, therefore it is not the owner of this metadata.

In OSP they have already made this mistake with Cinder that forces users that want to use snapshots to go through the Cinder API to have it be available in the OSP environment. Cinder doesn't know snapshot created on the storage and if you lose the Cinder you lose everything as the metadata that counts is in his stateful DB.

What I'm trying to say is that it is important that Kube doesn't try to be the owner of the volume metadata, which means things like periodically checking if a new snapshot was created directly via the storage service API or that the ID used for the snapshot is the storage service snapshot ID.

It is clear that Kube should expose snapshotting since it very needed to the container use case, but it is very important it doesn't become a storage abstraction service like Cinder. We do not want to chase the storage service features or limit user to use the Kube API, it should be a option. We also want to allow discovery of volumes no matter where they where created.

As we get to more complex features like QOS and oversubscription for example, we want to allow exposing and reusing the storage service capabilities, not replace them or block users from using them via the cloud service or storage management APIs.

@jingxu97 any progress on the feature description? @kubernetes/sig-storage-feature-requests

@mdelio @jingxu97 please, update the feature description with the new template - https://github.com/kubernetes/features/blob/master/ISSUE_TEMPLATE.md

@idvoretskyi I updated the original comment with the new template. This feature is not actually shipping any bits in the Kubernetes core for v1.7, so therefore I moved it to the next-milestone. This means that it will not need documentation, etc. for 1.7 in the Kubernetes core. I will remove the feature from the 1.7 tracking board as well.

@saad-ali any updates for 1.8? Is this feature still on track for the release?

cc @tsmetana

@idvoretskyi this is still on track: kubernetes-retired/external-storage#331

@jingxu97 @rootfs any update on missing docs for this? PR is due today.

Thanks @eagleusb ! I'll submit a placeholder doc soon.

Hi @xing-yang 👋

Thanks for your update. In the meantime, the docs placeholder deadline is almost here.

Please make sure to create a placeholder PR against the dev-1.20 branch in the k/website before the deadline.

Also, please keep in mind the important upcoming dates:

• Friday, Nov 6th: Week 8 - Docs Placeholder PR deadline
• Thursday, Nov 12th: Week 9 - Code Freeze
• Monday, Nov 23rd: Week 11 - Docs PR Ready for ReviewAs a reminder, please link all of your k/k PR as well as docs PR to this issue for the release team to track.

Hi @eagleusb ,

Thanks for the reminder! Doc PR is submitted here: kubernetes/website#24849

Hi @xing-yang

Looks like kubernetes/kubernetes#95282 is still open but being actively worked on. Just a reminder that Code Freeze is coming up in 2 days on Thursday, November 12th. All PRs must be merged by that date, otherwise an Exception is required.

Best,
Kirsten

Hi @kikisdeliveryservice ,

Thanks for the reminder! We are trying to get reviewers to finish reviewing and approving the PR by the 11/12 deadline.

Xing

This PR that updates snapshot CRDs to v1 for cluster addon is merged: kubernetes/kubernetes#96383
We are moving closer.

Great! just waiting on kubernetes/kubernetes#95282

@kikisdeliveryservice ,

kubernetes/kubernetes#95282 is approved. Just waiting for it to be merged:).

Yay! It's merged! Updating tracking sheet.

Congrats! 🎆

Thanks @kikisdeliveryservice!

Hi @xing-yang

Can you update the kep.yaml to reflect a status of implemented:

Once that merges we can then close this issue.

Thanks!
Kirsten

Hi @kikisdeliveryservice,

Will submit a PR soon. Thanks!

Xing

Thanks @xing-yang it's merged! Feel free to close this issue 😄

Hello, 1.21 Enhancement lead here.
I'm closing out this issue since the enhancement is GA and KEP has been updated to implemented.

/close

@annajung: Closing this issue.

Hi @jingxu97 👋 1.24 RT Comms lead here. I saw a note that the VolumeSnapshot v1beta1 CRD will be removed in 1.24. Would this be appropriate to include in our 1.24 Removals and Deprecations blog post?

Yes, I think so @mickeyboxell

@xing-yang

Thanks for confirming! @jingxu97 What information would you like communicated in the blog? I read that the functionality entered beta in 1.20 and was a little confused about the v1beta1 CRD now being removed. Did the project graduate to stable or was it replaced with an alternative API?

VolumeSnapshot went GA in 1.20
#1994
https://kubernetes.io/blog/2020/12/10/kubernetes-1.20-volume-snapshot-moves-to-ga/

@mickeyboxell I added that entry in the spreadsheet. VolumeSnapshot went GA in 1.20. Following K8s 1.21 release, we deprecated VolumeSnapshot v1beta1. Since VolumeSnapshot is out-of-tree CRD, we have the deprecation message in the release note here:
https://github.com/kubernetes-csi/external-snapshotter/releases/tag/v4.1.0

Now we are ready to remove VolumeSnapshot v1beta1 CRD in our next external-snapshotter release which will be v6.0, shortly after K8s 1.24 release.

We want to add a message in the deprecation/removal blog to indicate that VolumeSnapshot v1beta1 CRD will be removed in K8s 1.24.

Hope this helps.

@mickeyboxell In addition to the deprecation/removal blog, I'd also like to have a release note in K8s v1.24 release notes to indicate VolumeSnapshot v1beta1 CRD will be removed. Where can I add that release note?

I'm not sure how their process works. You may want to reach out to the #release-notes channel for more information.