Skip to content
Open
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
35 changes: 35 additions & 0 deletions csi.proto
Original file line number Diff line number Diff line change
Expand Up @@ -237,6 +237,14 @@ message PluginCapability {
// The presence of this capability determines whether the CO will
// attempt to invoke the OPTIONAL SnapshotMetadata service RPCs.
SNAPSHOT_METADATA_SERVICE = 4 [(alpha_enum_value) = true];

// SNAPSHOT_ACCESSIBILITY_CONSTRAINTS indicates that the snapshots
// for this plugin MAY NOT be equally accessible from all
// topologies in the cluster. The CO MUST use the topology
// information returned in the CreateSnapshotResponse to ensure
// that a desired volume can be provisioned from a given snapshot
// when scheduling workloads.
SNAPSHOT_ACCESSIBILITY_CONSTRAINTS = 5 [(alpha_enum_value) = true];
}
Type type = 1;
}
Expand Down Expand Up @@ -1229,6 +1237,19 @@ message CreateSnapshotRequest {
// - Specify primary or secondary for replication systems that
// support snapshotting only on primary.
map<string, string> parameters = 4;

// Specifies where (regions, zones, racks, etc.) the provisioned
// snapshot MUST be accessible from.
// An SP SHALL advertise the requirements for topological
// accessibility information in documentation. COs SHALL only specify
// topological accessibility information supported by the SP.
// This field is OPTIONAL.
// This field SHALL NOT be specified unless the SP has the
// SNAPSHOT_ACCESSIBILITY_CONSTRAINTS plugin capability.
// If this field is not specified and the SP has the
// SNAPSHOT_ACCESSIBILITY_CONSTRAINTS plugin capability, the SP MAY
// choose where the provisioned snapshot is accessible from.
TopologyRequirement accessibility_requirements = 5 [(alpha_field) = true];

@gnufied gnufied Jul 1, 2026

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why can't this be determined by SP from volume?

To be clear - I accept that we probably need the topology in CreateSnapshot response, but I am trying to think why we need this in the request.

Copy link
Copy Markdown
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This was one of the approaches that was considered but decided against because it would be good to support SPs that allow for creating Snapshots with topologies that differ from the source volume amongst other reasons. There is a more detailed explanation in the Alternatives Section of the KEP

}

message CreateSnapshotResponse {
Expand Down Expand Up @@ -1288,6 +1309,20 @@ message Snapshot {
// If this message is inside a VolumeGroupSnapshot message, the value
// MUST be the same as the group_snapshot_id in that message.
string group_snapshot_id = 6;

// Specifies where (regions, zones, racks, etc.) the provisioned
// snapshot is accessible from.
// A plugin that returns this field MUST also set the
// SNAPSHOT_ACCESSIBILITY_CONSTRAINTS plugin capability.
// An SP MAY specify multiple topologies to indicate the snapshot is
// accessible from multiple locations.
// COs MAY use this information to ensure that a desired volume can
// be provisioned from a given snapshot when scheduling workloads.
// This field is OPTIONAL. If it is not specified, the CO MAY assume
// the snapshot is equally accessible from all topologies in the
// cluster and MAY provision volumes referencing the snapshot as a
// source without topology constraints.
repeated Topology accessible_topology = 7 [(alpha_field) = true];
}
message DeleteSnapshotRequest {
// The ID of the snapshot to be deleted.
Expand Down
Loading