Fix failing csi-sanity tests

[chrishenzie]

There are three tests in csi-sanity that are currently skipped due to failures.

ListSnapshots [Controller Server] [It] should return snapshots that match the specified source volume id

  Expected
      <[]*csi.ListSnapshotsResponse_Entry | len:3, cap:4>: [
      ...
  to have length 1

This failure requires more investigation to find the root cause.

Node Service NodeExpandVolume [It] should fail when volume is not found

    unexpected error: resize requested for 1073741824 but after resize volume was size -1
    Expected
        <codes.Code>: 13
    to equal
        <codes.Code>: 5

The fake device utility library always returns a device path which causes issues when testing for devices not found. Additionally, any error found while trying to verify the device path is treated as an internal error (code 13) instead of not found (code 5).

We will need to likely need to return the specific error depending on the failure inside of VerifyDevicePath() in order to fix this.

Node Service NodeExpandVolume [It] should work if node-expand is called after node-publish

    rpc error: code = Internal desc = resize requested for 215822106624 but after resize volume was size -1

This issue occurs when blockdev is invoked to check the device size. Because we use a fake executor that doesn't print any output, we fail to parse any integer output from the blockdev command and return an error (and size -1) resulting in the test failure.

For possible fixes, we could potentially implement a custom fake executor that returns the expected output when it receives a blockdev command.

Tight coupling between mocks and csi-sanity

With the way we run csi-sanity right now (against a PD CSI driver with mocked components), it becomes difficult to coordinate behavior between tests and the mocked components because it's the entire suite ran against one instance of the server.

We could do things like run csi-sanity in stages against different instances of the PD CSI driver with different mocked components to ensure the expected behavior for specific tests, but that seems hacky at best and likely difficult to maintain as more tests are added.

We may also want to consider not mocking the executor and device utility library in case that allows us to test these cases more thoroughly and eliminate any coupling between the mocked components and test suite.

[k8s-triage-robot]

The Kubernetes project currently lacks enough contributors to adequately respond to all issues and PRs.

This bot triages issues and PRs according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue or PR as fresh with /remove-lifecycle stale
• Mark this issue or PR as rotten with /lifecycle rotten
• Close this issue or PR with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle stale

[chrishenzie]

/remove-lifecycle stale

[k8s-triage-robot]

The Kubernetes project currently lacks enough contributors to adequately respond to all issues and PRs.

This bot triages issues and PRs according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue or PR as fresh with /remove-lifecycle stale
• Mark this issue or PR as rotten with /lifecycle rotten
• Close this issue or PR with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle stale

[k8s-triage-robot]

The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs.

This bot triages issues and PRs according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue or PR as fresh with /remove-lifecycle rotten
• Close this issue or PR with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle rotten

[k8s-triage-robot]

The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs.

This bot triages issues and PRs according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Reopen this issue or PR with /reopen
• Mark this issue or PR as fresh with /remove-lifecycle rotten
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/close

[k8s-ci-robot]

@k8s-triage-robot: Closing this issue.

In response to this:

The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs.

This bot triages issues and PRs according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Reopen this issue or PR with /reopen
• Mark this issue or PR as fresh with /remove-lifecycle rotten
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/close

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.