Proto commits in container-storage-interface/spec

These commits are when the Protocol Buffers files have changed: (only the last 100 relevant commits are shown)

2024-10-22

Move VolumeGroupSnapshot to GA (#573)

The documentation is generated from this commit.

2024-03-14

Added the SnapshotMetadata service. (#551)

2024-03-05

update protoc and related (#552) * update protoc and related updated protoc to v25.2 updated protoc-gen-go to v1.32.0 added protoc-gen-go-grpc at v1.3.0 Modified the makefile to use "go install" to install tools. Use extended regular expressions in "sed" command. Fixes build on arm OSX host * fix github actions Always run "make build_go" on github actions Always update the timesptamp of spec.md/csi.proto to make sure lib/go is built on CI * remove github.com/golang/protobuf usage * simplify Makefile - use git to check for out-of-date generated files, avoids all the temp files and manual diff in the Makefile. - not specify version for protoc-gen-go, it will use the version from go.mod - do not copy over the protoc binary. Call it directly from unzipped path. So it can find the includes automatically, and we don't need the -I or --go_opts=Mxxx flags. - use paths=source_relative to generate go files directly into destination, avoid the copy. - simplify the sed command used to extract "csi.proto" file.

2023-08-04

Modify wording based on comments on August 3rd

2023-07-31

Spec ModifyVolume for QoS kep-3751

Modify wording based on comments on July 24th

Modify wording based on comments on July 25th

2023-03-04

Add alpha annotations

2023-02-21

Add new GroupControllerService and VolumeGroupSnapshot CSI RPCs (#519) * Add VolumeGroupSnapshot CSI RPCs

2022-11-01

Revert "Promote GetVolume and VolumeCondition to GA"

2022-10-20

Promote GetVolume and VolumeCondition to GA

2022-10-17

Move volume mount group feature GA

2022-09-22

correct errors in the spec Signed-off-by: Humble Chirammal <hchiramm@redhat.com>

2022-03-15

GetCapacityResponse: promote maximum_volume_size Kubernetes and several CSI drivers have been using that field for a while now and no changes to the semantic are expected, therefore the alpha status can and should be removed. The minimum_volume_size field is not used by Kubernetes. The semantic is probably stable, but further practical experience with it might be desirable before promoting it.

2021-07-23

Change required capability for published_node_ids in GetVolume Instead of PUBLISH_UNPUBLISH_VOLUME, use the LIST_VOLUMES_PUBLISHED_NODES capability to control the published_node_ids field in ControllerGetVolume. This change is to be more consistent with the existing behavior. It is a backwards-incompatible change, but the API is alpha. Also clarify the LIST_VOLUMES_PUBLISHED_NODES docs.

2021-06-07

Add spec change for volume mount group Apply suggestions from code review Co-authored-by: jdef <2348332+jdef@users.noreply.github.com>

Single node single/multi writer access modes

2021-04-19

relax node_id length limit to 256

2021-03-16

Add Secrets in NodeExpandVolumeRequest Signed-off-by: Patrik Cyvoct <patrik@ptrk.io>

2021-03-04

GetCapacityResponse: minimum volume size Using CapacityRange in GetCapacityResponse is not a good fit because the names of its fields is a bit awkward. By adding two fields in GetCapacityResponse we support the same functionality, plus they can be left unset separately from each other.

2021-02-16

GetCapacityResponse: volume size range The minimum volume size may also be relevant. Another advantage is that the existing CapacityRange type can be used.

2021-02-08

GetCapacityResponse: add maximum_volume_size This new field has a more precisely defined semantic than the existing available_capacity. It is intended for checking in advance in which topology a CreateVolume call might succeed. Checking that based on available_capacity is less precise, for example because fragmentation might prevent creating a single volume that uses all available capacity. The new value has to be returned in a message to allow the caller to determine whether the value was provided.

2021-01-23

Change size limitation for paths and node_id - Not put limit on paths length limiation. But add a minial support length floor. - Change node_id length limitation to 192 bytes

2020-04-13

Add Volume Health Support to CSI

2020-03-05

spec: added alpha_xxx options Enumerations, fields, messages, methods, and services support `alpha_xxx` designations, indicating that they are part of an experimental feature that may never evolve to "stable" status.

2020-02-11

clarify origin of volume_context The "volume context as returned by CO in CreateVolumeRequest" is misleading in several ways: - the volume context is return *to* the CO by the SP - it is returned in the CreateVolumeResponse

2019-10-21

Fix incorrectly named field The fields added to NodeGetVolumeStatsRequest and NodeExpandVolumeRequest should have been staging_target_path rather than staging_path. This change corrects that mistake. Also remove the extraneous "when possible" wording around when to supply these fields.

2019-10-18

Add volume capability to volume expansion calls Update specs and add new error code for invalid capabilities

2019-10-16

Add staging_path to NodeExpand/GetStats calls Allow COs to explicitly pass the staging path to node plugins when invoking NodeGetVolumeStats and NodeExpandVolume. Previously the CO could choose to pass either the staging or publish path, but there was no way for the node plugin to easily know which path it was. This change allows COs to pass both paths (if it wishes) or just the staging path, and in either case, the node plugin can easily figure out what it's being given. This makes its significantly easier for node plugins to implement the NodeGetVolumeStats and NodeExpandVolume RPCs, in particular it relieves the need to store some state on the node. For backwards compatibility, the field is not required, but it should be trivially easy for any CO to populate the field, so we encourage clients to set it. Release Note: ``` Added optional staging_target_path field to NodeExpandVolume() and NodeGetVolumeStats(). CO implementers should populate this new field if possible when calling these RPCs. ```

2019-08-28

Add PublishedNodes field to ListVolumes Response and wrap published_node_ids into a VolumeStatus message

2019-08-14

Adds secrets field to ListSnapshotsRequest (#372) There is no way to directly pass credentials to ListSnapshots call. This change will add a field required to pass credentials by the caller.

2019-03-04

Merge remote-tracking branch 'upstream/master' into fix/zone-correction

2019-03-03

Regenerate protobuf file Signed-off-by: Marc Solé <msolefonte@gmail.com>

2019-03-01

Add missing Type to PluginCapability_VolumeExpansion The PluginCapability_VolumeExpansion struct was missing a Type field to indicate which type of volume expansion is supported. This commit fixes that bug. Signed-off-by: Jose A. Rivera <jarrpa@redhat.com>

2019-02-22

Re-generated the csi proto file and the dependent golang library.

2018-11-26

Add support for volume expansion to CSI add support for volume expansion RPC calls. also add plugin capabilities that allow CO to query whether volume expansion is supported online or offline.

2018-11-17

spec.md: Fix than/then grammar mistake This commit fixes three occurrences of a grammar mistake in spec.md.

2018-11-15

Update the requirements for staging and target paths The vague wording around the staging and target paths left open too many possible implementations for raw block volumes, and implementors ended up doing non-obvious things. This change clarifies the contract between the CO and the SP when staging and publishing raw block volumes on the node. Specifically we now require that the CO creates the staging_target_path and that it is always a directory. And we require that the SP create the target_path and it should be a device file for blocks and a mount point for filesystems.

2018-11-14

spec: s/created_at/creation_time/

2018-11-13

spec: created_at is a Timestamp. Fixes #330

spec: rebase field numbers for v1 The spec package name was recently changed to v1, providing us the chance to properly number message fields starting from 1. * ControllerGetCapabilitiesResponse * GetPluginCapabilitiesResponse

2018-11-12

Change a stray `id` to `volume_id`

Scrub spec for "should", "must", etc. and capitalize

Bump CSI pkg ver in anticipation of 1.0 release

Clarify `CreateVolume` idepotent recovery behavior

2018-11-11

Clarify ID (volume, snapshot, & node) requirements.

Rename `id` to `volume_id` and `snapshot_id`.

Rename volume attributes and node publish info

2018-11-10

Clarify VolumeCapability and readonly on publish and stage

Remove stray empty line before capacity_range

Clarify VolumeCapability in CreateVolumeRequest Clarify why VolumeCapability in CreateVolumeRequest is a repeated list.

2018-11-09

spec: Clarify target_path and staging_target_path This patch clarifies the `target_path` and `staging_target_path` in the spec. It is CO's responsibility to make sure that SP has the permission to read or write `target_path` and `staging_target_path`, and is able to create files/directories if the path does not exist. This patch also changes the wording in `NodeStageVolume` call to enable those plugins that want to use the `NodeStageVolume` call as a lifecycle hook, but does not want to mount to the `staging_target_path`.

spec: Officially designated CSI extension number In anticipation of being granted an officially recognized protobuf extension range, modify the csi_secret field number to fall within the range designated for use by CSI. See https://github.com/protocolbuffers/protobuf/pull/5319

spec: csi_secret for volume validation

spec: simplify names of secrets fields

spec: label secret fields with csi_secret option * partial fix for #206

Add controller capability fo ControllerPublishVolume.readonly

Rename is_ready_to_use to ready_to_use

Address review comments

Change SnapshotStatus enum to a boolean This PR changes SnapshotStatus enum to a boolean is_ready_to_use and tries to use "processing" instead of "uploading" if possible to make it less specific.

spec: Add efficient volume cloning support With the new CSI snapshot feature it's now possible to create volumes from a snapshots. This may lead to users abusing it for unintended functionality, such as having a golden image to source new volumes. Most storage backends support efficient volume cloning, so it would be benefitial to expose this functionality in the CSI spec. By supporting cloning we avoid users creating a volume, and then a snapshot of that volume, just so it can be used as the source for new volumes. The VolumeContentSource, that was added by the snapshots feature, will be used for this feature. New VolumeSource message is added to the VolumeContentSource.

2018-11-08

Remove deprecated `NodeGetId` before 1.0

Rename ACCESSIBILITY_CONSTRAINTS to VOLUME_ACCESSIBILITY_CONSTRAINTS This PR renames ACCESSIBILITY_CONSTRAINTS to VOLUME_ACCESSIBILITY_CONSTRAINTS in preparation for adding topology support for snapshots.

Disallow control characters in name fields Earlier versions of the spec put no limits on name fields, but indicate that names should be usable as identifiers on storage backends. Control characers obviously conflict with this purpose, so specify that they're prohibitted, while making it clear that all other valid Unicode strings are allowed. Fixes #267

2018-11-07

spec: Correct another, old "supported" reference.

spec: remove topology from validate-volume. Current thinking is that topology of a volume can be discovered via the ListVolumes RPC of the controller and is not strictly required here. We can always add it back later if needed.

spec: extend validate volume response Since `parameters` and `volume_attributes` are complex fields the `Confirmed` message of `ValidateVolumeCapabilitiesResponse` has been extended to report those map entries recognized by the plugin.

spec: secrets for volume capability validation.

Fixed outdated comment.

spec: Align volume validation with creation. THIS IS A BREAKING CHANGE. * ValidateVolumeCapabilitiesRequest accepts the same parameters and topology requirements as CreateVolumeRequest. * ValidateVolumeCapabilitiesResponse is forward-compatible between newer COs (clients) and older plugins (servers). * fixes #242

2018-11-02

Generated files

2018-08-01

Write a design proposal for volume capacity Use repeated usage for representing volume stats

2018-05-31

Introduce concept of topology to CSI spec.

spec: Remove trailing spaces. Spec file has a number of unnecessary trailing spaces. This patch removes them.

2018-05-30

spec: Fix SnapshotSource commment Comment in SnapshotSource make references as if it were a newly created snapshot instead of a reference to a source snapshot. Talking about "created snapshot" and how this id will be used in subsequent calls may be confusing. Comment is changed to reflect that it is an already existing source snapshot.

spec: Volume from snapshot with different size There's no mention in the spec to expected behavior when the required_bytes in CreateVolumeRequest's capacity_range is larger or smaller than that of the VolumeContentSource. This may lead to different interpretations on the behavior. We are now explicit about expected behavior. If it's smaller we fail with OUT_OF_RANGE, and if it's greater the volume must be extended by the driver if necessary.

2018-05-24

spec: Add units for GetCapacityResponse GetCapacityResponse doesn't mention the units of the available_capacity field. From the rest of the document we can deduce that the units are bytes, but everywhere else in the spec we are explicit about it. We are now explicit about this field as well.

2018-05-21

Add NodeGetInfo to return node id and volume limits Add NodeGetInfo call and deprecate NodeGetId RPC

2018-05-18

spec: replace Readiness with WKT BoolValue

spec: Probe, s/readiness/ready/

spec: ProbeResponse reports readiness

spec: consistently document intentionally empty messages

2018-05-16

Add Snapshot Support in CSI Spec This PR proposes to add snapshot support in CSI specification. It proposes to add 3 new controller service RPCs, including CreateSnapshot, DeleteSnapshot, and ListSnapshots, and modify the existing ControllerGetCapabilitiesResponse and CreateVolumeRequest. There are several cases for using the snapshot data in a volume: 1. Create volume from snapshot: In this case, a new volume will be created on the storage backend and the data in the snapshot will be copied to the new volume. This case will be addressed by this proposal. 2. Revert snapshot: In this case, data in the original volume will be erased and replaced with data in the snapshot. This case is out of scope for this proposal and should be handled by a function of its own (not to be mixed with create volume from snapshot) if it is proposed in the future. The following changes will be made in the Service Controller: - Add CreateSnapshot - Add DeleteSnapshot - Add ListSnapshots - Modify CreateVolumeRequest to support creating a new volume from snapshot. - Modify ControllerGetCapabilitiesResponse to return CREATE_DELETE_SNAPSHOT and LIST_SNAPSHOTS support capabilities. - Create volume from snapshot is a REQUIRED functionality if CREATE_DELETE_SNAPSHOT is supported. This proposal was drafted here: https://docs.google.com/document/d/1oXVuDTNhXerr1UJ48tQrxF9J6vbm2LHVVC3z28655Qo/edit# The PR #207 is getting very big due to the large number of comments and some people can't view it on Github, so close that one and submit a new PR here instead.

2018-05-15

Add Snapshot Support in CSI Spec This PR proposes to add snapshot support in CSI specification. It proposes to add 3 new controller service RPCs, including CreateSnapshot, DeleteSnapshot, and ListSnapshots, and modify the existing ControllerGetCapabilitiesResponse and CreateVolumeRequest. There are several cases for using the snapshot data in a volume: 1. Create volume from snapshot: In this case, a new volume will be created on the storage backend and the data in the snapshot will be copied to the new volume. This case will be addressed by this proposal. 2. Revert snapshot: In this case, data in the original volume will be erased and replaced with data in the snapshot. This case is out of scope for this proposal and should be handled by a function of its own (not to be mixed with create volume from snapshot) if it is proposed in the future. The following changes will be made in the Service Controller: - Add CreateSnapshot - Add DeleteSnapshot - Add ListSnapshots - Modify CreateVolumeRequest to support creating a new volume from snapshot. - Modify ControllerGetCapabilitiesResponse to return CREATE_DELETE_SNAPSHOT and LIST_SNAPSHOTS support capabilities. - Create volume from snapshot is a REQUIRED functionality if CREATE_DELETE_SNAPSHOT is supported. This proposal was drafted here: https://docs.google.com/document/d/1oXVuDTNhXerr1UJ48tQrxF9J6vbm2LHVVC3z28655Qo/edit# The PR #207 is getting very big due to the large number of comments and some people can't view it on Github, so close that one and submit a new PR here instead.

Add Snapshot Support in CSI Spec This PR proposes to add snapshot support in CSI specification. It proposes to add 3 new controller service RPCs, including CreateSnapshot, DeleteSnapshot, and ListSnapshots, and modify the existing ControllerGetCapabilitiesResponse and CreateVolumeRequest. There are several cases for using the snapshot data in a volume: 1. Create volume from snapshot: In this case, a new volume will be created on the storage backend and the data in the snapshot will be copied to the new volume. This case will be addressed by this proposal. 2. Revert snapshot: In this case, data in the original volume will be erased and replaced with data in the snapshot. This case is out of scope for this proposal and should be handled by a function of its own (not to be mixed with create volume from snapshot) if it is proposed in the future. The following changes will be made in the Service Controller: - Add CreateSnapshot - Add DeleteSnapshot - Add ListSnapshots - Modify CreateVolumeRequest to support creating a new volume from snapshot. - Modify ControllerGetCapabilitiesResponse to return CREATE_DELETE_SNAPSHOT and LIST_SNAPSHOTS support capabilities. - Create volume from snapshot is a REQUIRED functionality if CREATE_DELETE_SNAPSHOT is supported. This proposal was drafted here: https://docs.google.com/document/d/1oXVuDTNhXerr1UJ48tQrxF9J6vbm2LHVVC3z28655Qo/edit# The PR #207 is getting very big due to the large number of comments and some people can't view it on Github, so close that one and submit a new PR here instead.

Add Snapshot Support in CSI Spec This PR proposes to add snapshot support in CSI specification. It proposes to add 3 new controller service RPCs, including CreateSnapshot, DeleteSnapshot, and ListSnapshots, and modify the existing ControllerGetCapabilitiesResponse and CreateVolumeRequest. There are several cases for using the snapshot data in a volume: 1. Create volume from snapshot: In this case, a new volume will be created on the storage backend and the data in the snapshot will be copied to the new volume. This case will be addressed by this proposal. 2. Revert snapshot: In this case, data in the original volume will be erased and replaced with data in the snapshot. This case is out of scope for this proposal and should be handled by a function of its own (not to be mixed with create volume from snapshot) if it is proposed in the future. The following changes will be made in the Service Controller: - Add CreateSnapshot - Add DeleteSnapshot - Add ListSnapshots - Modify CreateVolumeRequest to support creating a new volume from snapshot. - Modify ControllerGetCapabilitiesResponse to return CREATE_DELETE_SNAPSHOT and LIST_SNAPSHOTS support capabilities. - Create volume from snapshot is a REQUIRED functionality if CREATE_DELETE_SNAPSHOT is supported. This proposal was drafted here: https://docs.google.com/document/d/1oXVuDTNhXerr1UJ48tQrxF9J6vbm2LHVVC3z28655Qo/edit# The PR #207 is getting very big due to the large number of comments and some people can't view it on Github, so close that one and submit a new PR here instead.

Add Snapshot Support in CSI Spec This PR proposes to add snapshot support in CSI specification. It proposes to add 3 new controller service RPCs, including CreateSnapshot, DeleteSnapshot, and ListSnapshots, and modify the existing ControllerGetCapabilitiesResponse and CreateVolumeRequest. There are several cases for using the snapshot data in a volume: 1. Create volume from snapshot: In this case, a new volume will be created on the storage backend and the data in the snapshot will be copied to the new volume. This case will be addressed by this proposal. 2. Revert snapshot: In this case, data in the original volume will be erased and replaced with data in the snapshot. This case is out of scope for this proposal and should be handled by a function of its own (not to be mixed with create volume from snapshot) if it is proposed in the future. The following changes will be made in the Service Controller: - Add CreateSnapshot - Add DeleteSnapshot - Add ListSnapshots - Modify CreateVolumeRequest to support creating a new volume from snapshot. - Modify ControllerGetCapabilitiesResponse to return CREATE_DELETE_SNAPSHOT and LIST_SNAPSHOTS support capabilities. - Create volume from snapshot is a REQUIRED functionality if CREATE_DELETE_SNAPSHOT is supported. This proposal was drafted here: https://docs.google.com/document/d/1oXVuDTNhXerr1UJ48tQrxF9J6vbm2LHVVC3z28655Qo/edit# The PR #207 is getting very big due to the large number of comments and some people can't view it on Github, so close that one and submit a new PR here instead.

Add Snapshot Support in CSI Spec This PR proposes to add snapshot support in CSI specification. It proposes to add 3 new controller service RPCs, including CreateSnapshot, DeleteSnapshot, and ListSnapshots, and modify the existing ControllerGetCapabilitiesResponse and CreateVolumeRequest. There are several cases for using the snapshot data in a volume: 1. Create volume from snapshot: In this case, a new volume will be created on the storage backend and the data in the snapshot will be copied to the new volume. This case will be addressed by this proposal. 2. Revert snapshot: In this case, data in the original volume will be erased and replaced with data in the snapshot. This case is out of scope for this proposal and should be handled by a function of its own (not to be mixed with create volume from snapshot) if it is proposed in the future. The following changes will be made in the Service Controller: - Add CreateSnapshot - Add DeleteSnapshot - Add ListSnapshots - Modify CreateVolumeRequest to support creating a new volume from snapshot. - Modify ControllerGetCapabilitiesResponse to return CREATE_DELETE_SNAPSHOT and LIST_SNAPSHOTS support capabilities. - Create volume from snapshot is a REQUIRED functionality if CREATE_DELETE_SNAPSHOT is supported. This proposal was drafted here: https://docs.google.com/document/d/1oXVuDTNhXerr1UJ48tQrxF9J6vbm2LHVVC3z28655Qo/edit# The PR #207 is getting very big due to the large number of comments and some people can't view it on Github, so close that one and submit a new PR here instead.

Add Snapshot Support in CSI Spec This PR proposes to add snapshot support in CSI specification. It proposes to add 3 new controller service RPCs, including CreateSnapshot, DeleteSnapshot, and ListSnapshots, and modify the existing ControllerGetCapabilitiesResponse and CreateVolumeRequest. There are several cases for using the snapshot data in a volume: 1. Create volume from snapshot: In this case, a new volume will be created on the storage backend and the data in the snapshot will be copied to the new volume. This case will be addressed by this proposal. 2. Revert snapshot: In this case, data in the original volume will be erased and replaced with data in the snapshot. This case is out of scope for this proposal and should be handled by a function of its own (not to be mixed with create volume from snapshot) if it is proposed in the future. The following changes will be made in the Service Controller: - Add CreateSnapshot - Add DeleteSnapshot - Add ListSnapshots - Modify CreateVolumeRequest to support creating a new volume from snapshot. - Modify ControllerGetCapabilitiesResponse to return CREATE_DELETE_SNAPSHOT and LIST_SNAPSHOTS support capabilities. - Create volume from snapshot is a REQUIRED functionality if CREATE_DELETE_SNAPSHOT is supported. This proposal was drafted here: https://docs.google.com/document/d/1oXVuDTNhXerr1UJ48tQrxF9J6vbm2LHVVC3z28655Qo/edit# The PR #207 is getting very big due to the large number of comments and some people can't view it on Github, so close that one and submit a new PR here instead.

2018-04-20

make: add DNE comment to generated protobufs

2018-04-16

address review feedback

spec: use MUST when describing CapacityRange field reqs

2018-04-13

spec: Some consistency fix on map declarations

spec: Remove a reference to VolumeInfo VolumeInfo has been renamed to Volume in the spec. This patch fixed a reference to VolumeInfo in the spec.

2018-02-23

spec: proto package incorporates major version This patch also removes the `GetSupportedVersions` and per request Version field because of the newly introduced version in the package name.

Clarify wording and naming of credentials in CSI

2018-02-21

spec: consolidate xxxProbe calls into Identity.Probe * Remove ControllerProbe RPC. * Remove NodeController RPC. * Introduce Identity.Probe RPC, clarify its intent.

2018-02-20

Aligned spec.md error messages. Clarified some wording. Renamed to NodeStageVolume/NodeUnstageVolume. Addressed jdef comments. Added RPC interactions and reference counting section NodeStageVolume modifications: added publish_volume_info to response. Changed credential naming. Added credentials to unstage.

NodePublishDevice This patch handles issue #119 by adding two new RPCs, "NodePublishDevice" and "NodeUnpublishDevice". These RPCs MUST be called by the CO if the Node Plugin advertises the "PUBLISH_UNPUBLISH_DEVICE" capability. Plugins that advertise this capability SHOULD defer volume reference counting to the CO.

2018-02-16

Fix missing Type field from PluginCapability This patch fixes a missing field associated with the GetPluginCapabilities response from #189.