Skip to content

KEP-5943: Introducing Snapshot Topology #606

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.

Sign up for GitHub

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

Open
mdzraf wants to merge 1 commit into
base: master
Choose a base branch
from
+1,467 −1,333
Open

KEP-5943: Introducing Snapshot Topology #606

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
1 commit
Select commit
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
View file
Open in desktop
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.

@bswartz bswartz Jul 15, 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.

I'm uncomfortable with the word "accessible" here. The word has a specific meaning for volumes which doesn't apply to snapshots. What we are trying to communicate is not accessibility but whether the snapshot can be used to create volumes in a given topology. We don't really have a word that means that anywhere in the spec. I could imagine "located" or "usable from". We could use the awkward phrasing:

Specifies where (regions, zones, racks, etc.) volumes created from the provisioned snapshot MUST be accessible from.

This communicates the actual thing that CSI cares about, which is whether you can create a volume that is accessible in the topology in question, but I'm not sure it's exactly what we want to say.

If we introduced a new word:

Specifies where (regions, zones, racks, etc.) the provisioned snapshot MUST be usable from. A snapshot is usable from a location if volumes created from that snapshot are guaranteed to be accessible.

This is a little bit more clear. What do you think?

// 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];
Comment thread
mdzraf marked this conversation as resolved.
}

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