Skip to content

Latest commit

 

History

History
15 lines (13 loc) · 2.01 KB

csi.md

File metadata and controls

15 lines (13 loc) · 2.01 KB

Current status with respect to the Kubernetes CSIVolumeSource API

So let's take each part of the CSIVolumeSource:

  • for the Driver string field, it needs to be "csi-driver-projected-resource.openshift.io".
  • for the VolumeAttributes map, this driver currently adds the "share" key (which maps the the Share instance your Pod wants to use) in addition to the elements of the Pod the kubelet stores when contacting the driver to provision the Volume. See this list.
  • the ReadOnly field is honored. The driver can even update the content for a read-only Volume, even as the Pod consuming the Volume cannot write to the Volume. However, a limitation exists which makes any updates of content for read-only Volumes OFFICIALLY unsupported. Namely, the function will not work across driver restarts. The driver loses access to the kubelet's mount for the Volume. This is not the case for read-write Volumes. The driver is able to update the content of read-write Volumes provisioned before the latest restart of the driver.
  • Also, mounting of one Share off of a subdirectory of another Share is only supported with read-write Volumes.
  • the FSType field is ignored. This driver by design only supports tmpfs, with a different mount performed for each Volume, in order to defer all SELinux concerns to the kubelet.
  • the NodePublishSecretRef field is ignored. The CSI NodePublishVolume and NodeUnpublishVolume flows gate the permission evaluation required for the Volume by performing SubjectAccessReviews against the reference Share instance, using the serviceAccount of the Pod as the subject.