Move VolumeGroupSnapshot API to V1#1368
Move VolumeGroupSnapshot API to V1#1368xing-yang wants to merge 2 commits intokubernetes-csi:masterfrom
Conversation
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: xing-yang The full list of commands accepted by this bot can be found here. The pull request process is described here DetailsNeeds approval from an approver in each of these files:
Approvers can indicate their approval by writing |
f3adc74 to
9c1b77b
Compare
618d146 to
9f4c33e
Compare
|
/assign @jsafrane |
| type: object | ||
| served: true | ||
| storage: true | ||
| storage: false |
There was a problem hiding this comment.
How much do we care about downgrade of the external-snapshotter or snapshot-controller? If we store group snapshots as v1 and someone needs to downgrade the CRD, then they won't be able to access v1 objects as v1beta2.
If we provide both v1 and v1beta2 APIs, but store them internally as v1beta2, downgrade will work smoothly.
There was a problem hiding this comment.
When moving VolumeSnapshot to GA, we only store them as v1. Why should we do something different for VolumeGroupSnapshot? @msau42 what do you think?
|
I checked the v1 and v1beta2 types.go are the same + the generated CRDs look good. I did not check the generated code.
|
|
/hold |
8b8698c to
8f4c119
Compare
8f4c119 to
00de56b
Compare
00de56b to
97f3a71
Compare
|
Stress test is merged: kubernetes/kubernetes#136845 |
What type of PR is this?
/kind feature
What this PR does / why we need it:
This PR adds VolumeGroupSnapshot V1 API and tries to move the feature to GA.
Which issue(s) this PR fixes:
Fixes #
Special notes for your reviewer:
Does this PR introduce a user-facing change?: