What is behavior of CreateVolumeRequest with empty capacity_range?

[taaraora]

message CreateVolumeRequest {

  // This field is OPTIONAL. This allows the CO to specify the capacity
  // requirement of the volume to be provisioned. If not specified, the
  // Plugin MAY choose an implementation-defined capacity range. If
  // specified it MUST always be honored, even when creating volumes
  // from a source; which MAY force some backends to internally extend
  // the volume after creating it.
  CapacityRange capacity_range = 2;

Based on description, I suppose that Plugin MAY NOT choose an implementation-defined capacity, and in such case while handling CreateVolumeRequest having empty capacity_range Plugin MUST fail.
If my understanding is correct shall we update CreateVolume Errors table?

[jieyu]

If the capacity range is not specified by the CO, the SP should just use some default.

I suppose that Plugin MAY NOT choose an implementation-defined capacity

I don't quite get this ^

[msau42]

I agree with Dmytro that the spec is vague about the behavior a plugin should do when capacity is unspecified. It says it MAY choose a default, not MUST. So technically, returning an error is also a valid response according to the spec wording.

[msau42]

cc @jsafrane

[taaraora]

If the capacity range is not specified by the CO, the SP should just use some default.

I suppose that Plugin MAY NOT choose an implementation-defined capacity

I don't quite get this ^

Plugin MAY choose a default means that it is not obligatory and a plugin also may not use defaults (e. g. if a plugin is configured without default volume size being set).

[jdef]

I think it's valid for a plugin to respond with an error if no capacity is specified and the plugin is unable to reason about the capacity that it should use. It's also perfectly acceptable for a plugin to not require a capacity and successfully create a volume.

We could clarify this by expanding the corresponding error table w/ an explanation that the plugin may return an error for such cases. Given that it's likely either (a) a plugin configuration error, or else; (b) a limitation of the plugin .. then the CO should probably not retry the call as-is, and should instead supply the plugin with a capacity.

[saad-ali]

Discussed at community meeting on 2/11/20
See notes