KEP-5943: Introducing Snapshot Topology#606
Conversation
|
/assign @bswartz |
mdzraf
changed the title
|
Do we need to add some constraints for TopologyRequirement in CreateVolumeRequest if VolumeContentSource is a Snapshot? |
| // 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]; |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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
We can discuss this but we will already be enforcing it at provisioning time via the external-provisioner and the custom scheduler plugin. |
3 participants
What type of PR is this?
Introducing Snapshot Topology to CSI Spec.
What this PR does / why we need it:
This PR is part of the changes necessary for kubernetes/enhancements#5944
Special notes for your reviewer:
Does this PR introduce an API-breaking change?: