-
Notifications
You must be signed in to change notification settings - Fork 379
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
API change to improve VolumeGroupSnapshot restore #1068
API change to improve VolumeGroupSnapshot restore #1068
Conversation
Hi @leonardoce. Thanks for your PR. I'm waiting for a kubernetes-csi member to verify that this patch is reasonable to test. If it is, they should reply with Once the patch is verified, the new status will be reflected by the I understand the commands that are listed here. Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. |
Change `VolumeSnapshotRefList` in `VolumeGroupSnapshotStatus` to `PVCVolumeSnapshotRefList`, allowing users to map a `VolumeSnapshot` to a specific `PersistentVolumeClaim`. Change `VolumeSnapshotContentRefList` in `VolumeGroupSnapshotContentStatus` to `PVVolumeSnapshotContentRefList`, allowing users to map a `VolumeSnapshotContent` to a specific `PersistentVolume`. This two changes allow users to map each `VolumeSnapshot` back to the original PVC it was taken from.
This commit won't set any value in the new fields, but only change the logic to reproduce the behavior we already had.
248171c
to
7c8516f
Compare
/assign |
/ok-to-test |
// The maximum number of allowed snapshots in the group is 100. | ||
// +optional | ||
VolumeSnapshotRefList []core_v1.ObjectReference `json:"volumeSnapshotRefList,omitempty" protobuf:"bytes,5,opt,name=volumeSnapshotRefList"` | ||
PVCVolumeSnapshotRefList []PVCVolumeSnapshotPair `json:"pvcVolumeSnapshotRefList,omitempty" protobuf:"bytes,6,opt,name=pvcVolumeSnapshotRefList"` |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This should still be 5, not 6.
PVCVolumeSnapshotRefList []PVCVolumeSnapshotPair `json:"pvcVolumeSnapshotRefList,omitempty" protobuf:"bytes,6,opt,name=pvcVolumeSnapshotRefList"` | ||
} | ||
|
||
// PVCVolumeSnapshotPair defines a pair of a PVC reference and a Volume Snapshot |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Volume Snapshot reference
PersistentVolumeClaimRef core_v1.ObjectReference `json:"persistentVolumeClaimRef,omitempty" protobuf:"bytes,1,opt,name=persistentVolumeClaimRef"` | ||
|
||
// VolumeSnapshotRef is a reference to the VolumeSnapshot this pair is referring to | ||
VolumeSnapshotRef core_v1.ObjectReference `json:"volumeSnapshotRef,omitempty" protobuf:"bytes,1,opt,name=volumeSnapshotRef"` |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
2
// VolumeSnapshotContentRefList is the list of volume snapshot content references | ||
// for this group snapshot. | ||
// PVVolumeSnapshotContentRefList is the list of pairs of PV and | ||
// VolumeSnapshotCOntent for this group snapshot |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
PVVolumeSnapshotContentRefList -> PVVolumeSnapshotContentList
VolumeSnapshotCOntent -> VolumeSnapshotContent names
// The maximum number of allowed snapshots in the group is 100. | ||
// +optional | ||
VolumeSnapshotContentRefList []core_v1.ObjectReference `json:"volumeSnapshotContentRefList,omitempty" protobuf:"bytes,5,opt,name=volumeSnapshotContentRefList"` | ||
PVVolumeSnapshotContentRefList []PVVolumeSnapshotContentPair `json:"pvVolumeSnapshotContentRefList,omitempty" protobuf:"bytes,6,opt,name=pvVolumeSnapshotContentRefList"` |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
PVVolumeSnapshotContentRefList -> PVVolumeSnapshotContentList
PersistentVolumeName string `json:"persistentVolumeName,omitempty" protobuf:"bytes,1,opt,name=persistentVolumeName"` | ||
|
||
// VolumeSnapshotContentName is the name of the volume snapshot content resource | ||
VolumeSnapshotContentName string `json:"volumeSnapshotContentName,omitempty" protobuf:"bytes,1,opt,name=volumeSnapshotContentName"` |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
2
Thank you @xing-yang for reviewing this. I should have taken care of your comments. |
/assign @bswartz |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Actually after reviewing the change, I'm wondering why use object refs at all, if the PVC ref will always be a PVC and the snapshot ref will always be a VolumeSnapshot. Can't we do like the non-namespaced objects do and specify the object names, but omit their kinds? Namespace can be implied by the namespace of the containing object.
@@ -183,79 +183,101 @@ spec: | |||
format: date-time | |||
type: string | |||
type: object | |||
pvcVolumeSnapshotRefList: | |||
description: VolumeSnapshotRefList is the list of PVC and VolumeSnapshot | |||
pair that is part of this group snapshot. The maximum number of |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
pairs that are part
future.' | ||
type: string | ||
kind: | ||
description: 'Kind of the referent. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#types-kinds' |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Kind must be PVC!
future.' | ||
type: string | ||
kind: | ||
description: 'Kind of the referent. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#types-kinds' |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Kind must be VolumeSnapshot!
"Name" might be sufficient for now. I'm wondering we may want to keep the namespace just in case in the future there's namespace transfer support. |
Given `Kind` is implied in `pvcVolumeSnapshotRefList.persistentVolumeClaimRef` and in `pvcVolumeSnapshotRefList.volumeSnapshotRef`, let's avoid specifying it. Signed-off-by: Leonardo Cecchi <leonardo.cecchi@enterprisedb.com>
I replaced ObjectReferences with LocalObjectReferences and updated the code correspondingly. Thank you @bswartz @xing-yang |
LocalObjectReference looks good to me. We should probably use the same construct for PV and VolumeSnapshotContent pairs. |
Instead of using a field with the resource name, this patch uses LocalObjectReference in VolumeSnapshot too. This is being done for simmetry with VolumeGroupSnapshotContent. Signed-off-by: Leonardo Cecchi <leonardo.cecchi@enterprisedb.com>
Nice. I changed the code for this and updated the example in the PR description. |
Non-namespaced objects definitely should not be using namespaces. Assuming the kind is constant, why not just use an object name? |
@msau42 From API design point of view, are there pros and cons of using LocalObjectReference vs just a string here? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
/lgtm
Signed-off-by: Leonardo Cecchi <leonardo.cecchi@enterprisedb.com>
/lgtm |
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: bswartz, leonardoce, xing-yang The full list of commands accepted by this bot can be found here. The pull request process is described here
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
This commit introduces three new CustomResourceDefinitions (CRDs) for managing volume group snapshots within Kubernetes clusters: 1. VolumeGroupSnapshotClasses: Defines the properties and parameters required for volume group snapshot classes. 2. VolumeGroupSnapshotContents: Details the structure and management of on-disk group snapshot contents. 3. VolumeGroupSnapshots: Specifies user requests and properties for creating or binding to group snapshots. Each CRD is equipped with comprehensive specs, including fields like deletionPolicy, driver, and creationTime, tailored to enhance management capabilities and integration with the CSI driver specifications. Approved API references: - VolumeGroupSnapshotClasses: kubernetes-csi/external-snapshotter#814 - VolumeGroupSnapshotContents and VolumeGroupSnapshots: kubernetes-csi/external-snapshotter#1068 Signed-off-by: Manish <myathnal@redhat.com>
This commit introduces three new CustomResourceDefinitions (CRDs) for managing volume group snapshots within Kubernetes clusters: 1. VolumeGroupSnapshotClasses: Defines the properties and parameters required for volume group snapshot classes. 2. VolumeGroupSnapshotContents: Details the structure and management of on-disk group snapshot contents. 3. VolumeGroupSnapshots: Specifies user requests and properties for creating or binding to group snapshots. Each CRD is equipped with comprehensive specs, including fields like deletionPolicy, driver, and creationTime, tailored to enhance management capabilities and integration with the CSI driver specifications. Approved API references: - VolumeGroupSnapshotClasses: kubernetes-csi/external-snapshotter#814 - VolumeGroupSnapshotContents and VolumeGroupSnapshots: kubernetes-csi/external-snapshotter#1068 Signed-off-by: Manish <myathnal@redhat.com>
This commit introduces three new CustomResourceDefinitions (CRDs) for managing volume group snapshots within Kubernetes clusters: 1. VolumeGroupSnapshotClasses: Defines the properties and parameters required for volume group snapshot classes. 2. VolumeGroupSnapshotContents: Details the structure and management of on-disk group snapshot contents. 3. VolumeGroupSnapshots: Specifies user requests and properties for creating or binding to group snapshots. Each CRD is equipped with comprehensive specs, including fields like deletionPolicy, driver, and creationTime, tailored to enhance management capabilities and integration with the CSI driver specifications. Approved API references: - VolumeGroupSnapshotClasses: kubernetes-csi/external-snapshotter#814 - VolumeGroupSnapshotContents and VolumeGroupSnapshots: kubernetes-csi/external-snapshotter#1068 Signed-off-by: Manish <myathnal@redhat.com>
This commit introduces three new CustomResourceDefinitions (CRDs) for managing volume group snapshots within Kubernetes clusters: 1. VolumeGroupSnapshotClasses: Defines the properties and parameters required for volume group snapshot classes. 2. VolumeGroupSnapshotContents: Details the structure and management of on-disk group snapshot contents. 3. VolumeGroupSnapshots: Specifies user requests and properties for creating or binding to group snapshots. Each CRD is equipped with comprehensive specs, including fields like deletionPolicy, driver, and creationTime, tailored to enhance management capabilities and integration with the CSI driver specifications. Approved API references: - VolumeGroupSnapshotClasses: kubernetes-csi/external-snapshotter#814 - VolumeGroupSnapshotContents and VolumeGroupSnapshots: kubernetes-csi/external-snapshotter#1068 Signed-off-by: Manish <myathnal@redhat.com>
This commit introduces three new CustomResourceDefinitions (CRDs) for managing volume group snapshots within Kubernetes clusters: 1. VolumeGroupSnapshotClasses: Defines the properties and parameters required for volume group snapshot classes. 2. VolumeGroupSnapshotContents: Details the structure and management of on-disk group snapshot contents. 3. VolumeGroupSnapshots: Specifies user requests and properties for creating or binding to group snapshots. Each CRD is equipped with comprehensive specs, including fields like deletionPolicy, driver, and creationTime, tailored to enhance management capabilities and integration with the CSI driver specifications. Approved API references: - VolumeGroupSnapshotClasses: kubernetes-csi/external-snapshotter#814 - VolumeGroupSnapshotContents and VolumeGroupSnapshots: kubernetes-csi/external-snapshotter#1068 Signed-off-by: Manish <myathnal@redhat.com>
This commit introduces three new CustomResourceDefinitions (CRDs) for managing volume group snapshots within Kubernetes clusters: 1. VolumeGroupSnapshotClasses: Defines the properties and parameters required for volume group snapshot classes. 2. VolumeGroupSnapshotContents: Details the structure and management of on-disk group snapshot contents. 3. VolumeGroupSnapshots: Specifies user requests and properties for creating or binding to group snapshots. Each CRD is equipped with comprehensive specs, including fields like deletionPolicy, driver, and creationTime, tailored to enhance management capabilities and integration with the CSI driver specifications. Approved API references: - VolumeGroupSnapshotClasses: kubernetes-csi/external-snapshotter#814 - VolumeGroupSnapshotContents and VolumeGroupSnapshots: kubernetes-csi/external-snapshotter#1068 Signed-off-by: Manish <myathnal@redhat.com>
This commit introduces three new CustomResourceDefinitions (CRDs) for managing volume group snapshots within Kubernetes clusters: 1. VolumeGroupSnapshotClasses: Defines the properties and parameters required for volume group snapshot classes. 2. VolumeGroupSnapshotContents: Details the structure and management of on-disk group snapshot contents. 3. VolumeGroupSnapshots: Specifies user requests and properties for creating or binding to group snapshots. Each CRD is equipped with comprehensive specs, including fields like deletionPolicy, driver, and creationTime, tailored to enhance management capabilities and integration with the CSI driver specifications. Approved API references: - VolumeGroupSnapshotClasses: kubernetes-csi/external-snapshotter#814 - VolumeGroupSnapshotContents and VolumeGroupSnapshots: kubernetes-csi/external-snapshotter#1068 Signed-off-by: Manish <myathnal@redhat.com>
This commit introduces three new CustomResourceDefinitions (CRDs) for managing volume group snapshots within Kubernetes clusters: 1. VolumeGroupSnapshotClasses: Defines the properties and parameters required for volume group snapshot classes. 2. VolumeGroupSnapshotContents: Details the structure and management of on-disk group snapshot contents. 3. VolumeGroupSnapshots: Specifies user requests and properties for creating or binding to group snapshots. Each CRD is equipped with comprehensive specs, including fields like deletionPolicy, driver, and creationTime, tailored to enhance management capabilities and integration with the CSI driver specifications. Approved API references: - VolumeGroupSnapshotClasses: kubernetes-csi/external-snapshotter#814 - VolumeGroupSnapshotContents and VolumeGroupSnapshots: kubernetes-csi/external-snapshotter#1068 Signed-off-by: Manish <myathnal@redhat.com>
This commit introduces three new CustomResourceDefinitions (CRDs) for managing volume group snapshots within Kubernetes clusters: 1. VolumeGroupSnapshotClasses: Defines the properties and parameters required for volume group snapshot classes. 2. VolumeGroupSnapshotContents: Details the structure and management of on-disk group snapshot contents. 3. VolumeGroupSnapshots: Specifies user requests and properties for creating or binding to group snapshots. Each CRD is equipped with comprehensive specs, including fields like deletionPolicy, driver, and creationTime, tailored to enhance management capabilities and integration with the CSI driver specifications. Approved API references: - VolumeGroupSnapshotClasses: kubernetes-csi/external-snapshotter#814 - VolumeGroupSnapshotContents and VolumeGroupSnapshots: kubernetes-csi/external-snapshotter#1068 Signed-off-by: Manish <myathnal@redhat.com>
This commit introduces three new CustomResourceDefinitions (CRDs) for managing volume group snapshots within Kubernetes clusters: 1. VolumeGroupSnapshotClasses: Defines the properties and parameters required for volume group snapshot classes. 2. VolumeGroupSnapshotContents: Details the structure and management of on-disk group snapshot contents. 3. VolumeGroupSnapshots: Specifies user requests and properties for creating or binding to group snapshots. Each CRD is equipped with comprehensive specs, including fields like deletionPolicy, driver, and creationTime, tailored to enhance management capabilities and integration with the CSI driver specifications. Approved API references: - VolumeGroupSnapshotClasses: kubernetes-csi/external-snapshotter#814 - VolumeGroupSnapshotContents and VolumeGroupSnapshots: kubernetes-csi/external-snapshotter#1068 Signed-off-by: Manish <myathnal@redhat.com>
This commit introduces three new CustomResourceDefinitions (CRDs) for managing volume group snapshots within Kubernetes clusters: 1. VolumeGroupSnapshotClasses: Defines the properties and parameters required for volume group snapshot classes. 2. VolumeGroupSnapshotContents: Details the structure and management of on-disk group snapshot contents. 3. VolumeGroupSnapshots: Specifies user requests and properties for creating or binding to group snapshots. Each CRD is equipped with comprehensive specs, including fields like deletionPolicy, driver, and creationTime, tailored to enhance management capabilities and integration with the CSI driver specifications. Approved API references: - VolumeGroupSnapshotClasses: kubernetes-csi/external-snapshotter#814 - VolumeGroupSnapshotContents and VolumeGroupSnapshots: kubernetes-csi/external-snapshotter#1068 Signed-off-by: Manish <myathnal@redhat.com>
What type of PR is this?
/kind api-change
What this PR does / why we need it:
This PR implements an API change proposed by @xing-yang (see https://docs.google.com/document/d/1NdNwFD5Z64K2heQLYOnojt6Ogulg750BuYIJ6W9cEiM/edit?usp=sharing and the relative conversation in #969).
To ease the review process, this PR has been split into two commits:
The information we have in
VolumeGroupSnapshot.status.volumeSnapshotRefList
has been moved intoVolumeGroupSnapshot.status.pvcVolumeSnapshotRefList.volumeSnapshotRef
.The information we have in
VolumeGroupSnapshotContent.status.volumeSnapshotContentRefList
has been moved intoVolumeGroupSnapshotContent.status.volumeSnapshotContentRefList.volumeSnapshotContentName
.The code to set the new fields has already been implemented, and I'm going to open a new PR based on this one.
I hope that it will be helpful for the reviewer.
If you prefer a single PR on multiple commits, just tell me.
Which issue(s) this PR fixes:
Fixes #
Special notes for your reviewer:
This is my first API-change PR. I followed the process described in
client/hack/README.md
as carefully as possible, but I encourage you to use special care when reviewing this.Testing
After this patch, a
VolumeGroupSnapshot
will be defined as:And the corresponding VolumeGroupSnapshotContent would be like:
Does this PR introduce a user-facing change?: