Test fails if CapacityBytes is always 0

[ctrox]

According to the CreateVolume specs a volume should not set CapacityBytes (or set it to 0) to indicate that the capacity is unknown.

  // The capacity of the volume in bytes. This field is OPTIONAL. If not
  // set (value of 0), it indicates that the capacity of the volume is
  // unknown (e.g., NFS share).
  // The value of this field MUST NOT be negative.
  int64 capacity_bytes = 1;

When running the test CreateVolume [Controller Server] [It] should fail when requesting to create a volume with already exisiting name and different capacity. it fails as it is not possible to detect this if the volume capacity is always 0.

The test CreateVolume [Controller Server] [It] should not fail when requesting to create a volume with already exisiting name and same capacity. also fails but as far as I can see this can be fixed by setting TestVolumeSize: 0.

[lpabon]

Great point. I will check this out.

[fejta-bot]

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/lifecycle stale

[fejta-bot]

Stale issues rot after 30d of inactivity.
Mark the issue as fresh with /remove-lifecycle rotten.
Rotten issues close after an additional 30d of inactivity.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/lifecycle rotten

[msau42]

/lifecycle frozen
/help

[k8s-ci-robot]

@msau42:
This request has been marked as needing help from a contributor.

Please ensure the request meets the requirements listed here.

If this request no longer meets these requirements, the label can be removed
by commenting with the /remove-help command.

In response to this:

/lifecycle frozen
/help

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

[Kartik494]

@ctrox could you please elaborate in this test -
CreateVolume [Controller Server] [It] should not fail when requesting to create a volume with already exisiting name and same capacity. also fails but as far as I can see this can be fixed by setting TestVolumeSize: 0
by setting TestVolumeSize: 0 As volume with already existing name and same capacity name should MUST reply 0 OK with the corresponding CreateVolumeResponse.
and in https://github.com/kubernetes-csi/csi-test/blob/master/pkg/sanity/sanity.go
TestVolumeSize is 10GiB co can u please explain how VolumeSize test pass on 0 bytes rather 10 GiB.
Thanks

[NicolasT]

Running into something similar for an NFS-backed plugin: CreateVolume should return appropriate values SingleNodeWrite WithCapacity 1Gi type: Mount results in Expected <int64>: 0 to be >= <int64>: 10737418240.

According to the CSI spec, it should be perfectly legal for my controller plugin to return a capacity_bytes of 0 in the returned Volume, right?

[NicolasT]

Related: the should fail when requesting to create a volume with already existing name and different capacity test: when using a storage system with unbounded capacity, the returned capacity_bytes of the initial CreateVolume request can be 0, and there's not really a reason for the SP to store the requested size for the volume anywhere.

Now, if a new CreateVolume for the same name and requested size comes in, the operation should be idempotent. Fine. However, according to the test (though IMO not according to the CSI spec...) when such request comes in for the same name but a different requested size, the call should fail with ALREADY_EXISTS, which would require the SP to somehow store the requested (and potentially 'expanded') size of the original volume creation request.

The spec says:

Volume already exists but is incompatible (6 ALREADY_EXISTS)
Indicates that a volume corresponding to the specified volume name already exists but is incompatible with the specified capacity_range, volume_capabilities or parameters.

I'd argue a volume of capacity_bytes 0 is compatible with any capacity_range, so not sure it should fail as the test implies.

[NicolasT]

Hmh, upon re-reading, what I wrote above is exactly the initial bug report 😊