Skip to content
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

GetCapacityResponse: add maximum_volume_size #470

Merged
merged 3 commits into from
Mar 4, 2021
Merged

GetCapacityResponse: add maximum_volume_size #470

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
3 commits
Select commit Hold shift + click to select a range
e09188b
GetCapacityResponse: add maximum_volume_size
pohly Feb 4, 2021
0600cb2
GetCapacityResponse: volume size range
pohly Feb 16, 2021
7a2fcdd
GetCapacityResponse: minimum volume size
pohly Feb 17, 2021
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
36 changes: 36 additions & 0 deletions csi.proto
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -947,6 +947,42 @@ message GetCapacityResponse {
// storage. This field is REQUIRED.
// The value of this field MUST NOT be negative.
int64 available_capacity = 1;
Copy link
Contributor

Choose a reason for hiding this comment

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

Now that we have added the new capacity fields for max/min volume size, can we also add comments to this existing field to explain how CO should be using this field?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I think that is not clear yet. If you have a proposal, then please put it into a PR and we can discuss it.


// The largest size that may be used in a
Copy link

Choose a reason for hiding this comment

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

For volume plugins that don't need to deal with fragmentation issues, I think defining a stricter available_capacity would be beneficial to help us do batch processing of multiple volumes. Right now, we're limited to processing a single volume at a time, which is a major issue for supporting a single workload that requests multiple volumes.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Improving the definition of available_capacity was intentionally left out because it seemed to need further discussion.

Copy link

Choose a reason for hiding this comment

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

I meant should we define a new available_capacity field that has a more strict definition?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Yes, probably. But not in this PR 😅

What you want is tracked in #301

Copy link

Choose a reason for hiding this comment

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

Not quite. So we said available_capacity could be interpreted 2 ways: 1) available capacity to provision a single volume and 2) total available capacity as reported by the storage system. Why do we only want to clarify one of the methods that this could be interpreted?

Copy link
Contributor Author

@pohly pohly Mar 1, 2021 •
edited
Loading

Choose a reason for hiding this comment

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

In the last CSI community meeting we talked about whether available_capacity should be clarified and concluded that the wording should be left as-is until there is a specific use-case that needs a stricter definition than the one that is currently in the spec. See (or rather, listen): https://www.youtube.com/watch?list=PLypWp79Fch09Sv7Vo-mHgEo20cGU7oNBc&t=1917&v=ZB0Y05jo7-M&feature=youtu.be

That link points to my summary of the discussion; both @bswartz and @saad-ali confirmed it.

// CreateVolumeRequest.capacity_range.required_bytes field
// to create a volume with the same parameters as those in
// GetCapacityRequest.
//
// If `volume_capabilities` or `parameters` is
// specified in the request, the Plugin SHALL take those into
// consideration when calculating the minimum volume size of the
// storage.
//
// This field is OPTIONAL. MUST NOT be negative.
// The Plugin SHOULD provide a value for this field if it has
// a maximum size for individual volumes and leave it unset
// otherwise. COs MAY use it to make decision about
// where to create volumes.
google.protobuf.Int64Value maximum_volume_size = 2
[(alpha_field) = true];
Copy link
Contributor Author

Choose a reason for hiding this comment

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

The line break is necessary here to pass the length > 72 check.


// The smallest size that may be used in a
// CreateVolumeRequest.capacity_range.limit_bytes field
// to create a volume with the same parameters as those in
// GetCapacityRequest.
//
// If `volume_capabilities` or `parameters` is
// specified in the request, the Plugin SHALL take those into
// consideration when calculating the maximum volume size of the
// storage.
//
// This field is OPTIONAL. MUST NOT be negative.
// The Plugin SHOULD provide a value for this field if it has
// a minimum size for individual volumes and leave it unset
// otherwise. COs MAY use it to make decision about
// where to create volumes.
google.protobuf.Int64Value minimum_volume_size = 3
[(alpha_field) = true];
}
message ControllerGetCapabilitiesRequest {
// Intentionally empty.
Expand Down
Loading