Things are slowly starting to fall into place, although it’s unfortunate I don’t speak Japanese!
Sorry, I describe your questions as much as I can in English
and the “node” part responds to attach/detach requests (from the kubelet).
To be exact, “controller” part responds to attach/detach requests too(from GitHub - kubernetes-csi/external-attacher: Sidecar container that watches Kubernetes VolumeAttachment objects and triggers ControllerPublish/Unpublish against a CSI endpoint ).
The main role of “node” part is reponding to mount/umount request(from kubelet).
(mount/umount request = Node(Un)stageVolume/Node(Un)publishVolume)
I wonder then what would be the correct way to write something like csi-driver-host-path but which works across multiple nodes. At volume creation time, it needs to choose a node to create the volume on (unless the PVC requested a specific node);
Kubernetes CSI supports the Topology feature.
If you want to select a node, you need to use the Topology feature.
I don’t know much local-zfs-provisioner, but maybe GitHub - topolvm/topolvm: Capacity-aware CSI plugin for Kubernetes is closed to you want to know.
The whole reason I started down this path is because local-zfs-provisioner doesn’t support volume resize operations, and in turn this is because it uses sig-storage-lib-external-provisioner which doesn’t support resize.
CSI Driver can inform what feature was supported using the capability to sidecar apps and kubelet(also whether support a resize feature).
# Container Storage Interface (CSI)
Authors:
* Jie Yu <<jie@mesosphere.io>> (@jieyu)
* Saad Ali <<saadali@google.com>> (@saad-ali)
* James DeFelice <<james@mesosphere.io>> (@jdef)
* <container-storage-interface-working-group@googlegroups.com>
## Notational Conventions
The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as described in [RFC 2119](http://tools.ietf.org/html/rfc2119) (Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997).
The key words "unspecified", "undefined", and "implementation-defined" are to be interpreted as described in the [rationale for the C99 standard](http://www.open-std.org/jtc1/sc22/wg14/www/C99RationaleV5.10.pdf#page=18).
An implementation is not compliant if it fails to satisfy one or more of the MUST, REQUIRED, or SHALL requirements for the protocols it implements.
An implementation is compliant if it satisfies all the MUST, REQUIRED, and SHALL requirements for the protocols it implements.
## Terminology
This file has been truncated. show original
# Container Storage Interface (CSI)
Authors:
* Jie Yu <<jie@mesosphere.io>> (@jieyu)
* Saad Ali <<saadali@google.com>> (@saad-ali)
* James DeFelice <<james@mesosphere.io>> (@jdef)
* <container-storage-interface-working-group@googlegroups.com>
## Notational Conventions
The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as described in [RFC 2119](http://tools.ietf.org/html/rfc2119) (Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997).
The key words "unspecified", "undefined", and "implementation-defined" are to be interpreted as described in the [rationale for the C99 standard](http://www.open-std.org/jtc1/sc22/wg14/www/C99RationaleV5.10.pdf#page=18).
An implementation is not compliant if it fails to satisfy one or more of the MUST, REQUIRED, or SHALL requirements for the protocols it implements.
An implementation is compliant if it satisfies all the MUST, REQUIRED, and SHALL requirements for the protocols it implements.
## Terminology
This file has been truncated. show original
And an application that requests to a resizes request to CSI Driver is GitHub - kubernetes-csi/external-resizer: Sidecar container that watches Kubernetes PersistentVolumeClaims objects and triggers controller side expansion operation against a CSI endpoint .
Maybe sig-storage-lib-external-provisioner is a library that only executes provisioning a volume(create/delete a volume).
sig-storage-lib-external-provisioner is being used from an external-provisioner.
It’s not that I need this functionality - it’s more that I want to understand how this all hangs together, and storage provisioning in k8s in general. So thank you for helping my understanding