CSI driver should not rely on device path reported by OpenStack

[jsafrane]

/kind bug

What happened:
I'm running CSI driver from this repo and my volume got attached as /dev/vdc, while CSI driver returned DevicePath: /dev/vdb as attachment metadata.

This volume cannot be mounted into a pod because NodePublish can't find the volume.

What you expected to happen:
The driver either reports DevicePath or it's able to find the volume on the node without trusting DevicePath.

How to reproduce it (as minimally and precisely as possible):
I don't know what I did to OpenStack to attach the volume as /dev/vdc instead of /dev/vdb (there is no vdb device), but since that happened I can reproduce the bug reliably by just creating a pod.

Environment:

• openstack-cloud-controller-manager version:
  I don't have access to the actual servers...

# nova  version-list
Client supported API versions:
Minimum version 2.1
Maximum version 2.53

Server supported API versions:
+------+-----------+----------------------+-------------+---------+
| Id   | Status    | Updated              | Min Version | Version |
+------+-----------+----------------------+-------------+---------+
| v2.0 | SUPPORTED | 2011-01-21T11:33:21Z |             |         |
| v2.1 | CURRENT   | 2013-07-23T11:33:21Z | 2.1         | 2.38    |
+------+-----------+----------------------+-------------+---------+

# cinder version-list
Client supported API versions:
Minimum version 3.0
Maximum version 3.40

Server supported API versions:
+------+------------+----------------------+-------------+---------+
| Id   | Status     | Updated              | Min Version | Version |
+------+------------+----------------------+-------------+---------+
| v1.0 | DEPRECATED | 2016-05-02T20:25:19Z |             |         |
| v2.0 | SUPPORTED  | 2014-06-28T12:20:21Z |             |         |
| v3.0 | CURRENT    | 2016-02-08T12:20:21Z | 3.0         | 3.15    |
+------+------------+----------------------+-------------+---------+

• OS (e.g. from /etc/os-release): Red Hat Enterprise Linux Server 7.5
• Kernel (e.g. uname -a): 3.10.0-862.el7.x86_64
• Install tools: manually

[jsafrane]

This has been fixed in Kubernetes internal Cidner volume plugin in kubernetes/kubernetes#33128 by introducing TrustDevicePath config option.

[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

[fejta-bot]

Rotten issues close after 30d of inactivity.
Reopen the issue with /reopen.
Mark the issue as fresh with /remove-lifecycle rotten.

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

[k8s-ci-robot]

@fejta-bot: Closing this issue.

In response to this:

Rotten issues close after 30d of inactivity.
Reopen the issue with /reopen.
Mark the issue as fresh with /remove-lifecycle rotten.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/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.