fix(provisioning): register topologyKeys from driver env (#395)

Signed-off-by: shubham <shubham14bajpai@gmail.com>

docs/faq.md

@@ -91,7 +91,12 @@ spec:
 
 ### 6. How to add custom topology key
 
-To add custom topology key, we can label all the nodes with the required key and value :-
+To add custom topology key:
+* Label the nodes with the required key and value.
+* Set env variables in the ZFS driver daemonset yaml(openebs-zfs-node), if already deployed, you can edit the daemonSet directly. By default the env is set to `All` which will take the node label keys as allowed topologies.
+* "openebs.io/nodename" and "openebs.io/nodeid" are added as default topology key. 
+* Create storageclass with above specific labels keys.
+
 
 ```sh
 $ kubectl label node pawan-node-1 openebs.io/rack=rack1
@@ -101,12 +106,25 @@ $ kubectl get nodes pawan-node-1 --show-labels
 NAME           STATUS   ROLES    AGE   VERSION   LABELS
 pawan-node-1   Ready    worker   16d   v1.17.4   beta.kubernetes.io/arch=amd64,beta.kubernetes.io/os=linux,kubernetes.io/arch=amd64,kubernetes.io/hostname=pawan-node-1,kubernetes.io/os=linux,node-role.kubernetes.io/worker=true,openebs.io/rack=rack1
 
+$ kubectl get ds -n kube-system openebs-zfs-node -o yaml
+...
+env:
+  - name: OPENEBS_NODE_ID
+    valueFrom:
+      fieldRef:
+        fieldPath: spec.nodeName
+  - name: OPENEBS_CSI_ENDPOINT
+    value: unix:///plugin/csi.sock
+  - name: OPENEBS_NODE_DRIVER
+    value: agent
+  - name: OPENEBS_NAMESPACE
+    value: openebs
+  - name: ALLOWED_TOPOLOGIES
+    value: "openebs.io/rack"
 ```
 It is recommended is to label all the nodes with the same key, they can have different values for the given keys, but all keys should be present on all the worker node.
 
-Once we have labeled the node, we can install the zfs driver. The driver will pick the node labels and add that as the supported topology key. If the driver is already installed and you want to add a new topology information, you can label the node with the topology information and then restart of the ZFSPV CSI driver daemon sets (openebs-zfs-node) are required so that the driver can pick the labels and add them as supported topology keys. We should restart the pod in kube-system namespace with the name as openebs-zfs-node-[xxxxx] which is the node agent pod for the ZFS-LocalPV Driver.
-
-Note that restart of ZFSPV CSI driver daemon sets are must in case, if we are going to use WaitForFirstConsumer as volumeBindingMode in storage class. In case of immediate volume binding mode, restart of daemon set is not a must requirement, irrespective of sequence of labeling the node either prior to install zfs driver or after install. However it is recommended to restart the daemon set if we are labeling the nodes after the installation.
+Once we have labeled the node, we can install the zfs driver. The driver will pick the keys from env "ALLOWED_TOPOLOGIES" and add that as the supported topology key. If the driver is already installed and you want to add a new topology information, you can edit the ZFS-LocalPV CSI driver daemon sets (openebs-zfs-node).
 
 ```sh
 $ kubectl get pods -n kube-system -l role=openebs-zfs
@@ -140,12 +158,8 @@ spec:
   - name: zfs.csi.openebs.io
     nodeID: pawan-node-1
     topologyKeys:
-    - beta.kubernetes.io/arch
-    - beta.kubernetes.io/os
-    - kubernetes.io/arch
-    - kubernetes.io/hostname
-    - kubernetes.io/os
-    - node-role.kubernetes.io/worker
+    - openebs.io/nodeid
+    - openebs.io/nodename
     - openebs.io/rack
 ```
 
@@ -170,7 +184,7 @@ allowedTopologies:
 
 The ZFSPV CSI driver will schedule the PV to the nodes where label "openebs.io/rack" is set to "rack1". If there are multiple nodes qualifying this prerequisite, then it will pick the node which has less number of volumes provisioned for the given ZFS Pool.
 
-Note that if storageclass is using Immediate binding mode and topology key is not mentioned then all the nodes should be labeled using same key, that means, same key should be present on all nodes, nodes can have different values for those keys. If nodes are labeled with different keys i.e. some nodes are having different keys, then ZFSPV's default scheduler can not effictively do the volume count based scheduling. Here, in this case the CSI provisioner will pick keys from any random node and then prepare the preferred topology list using the nodes which has those keys defined and ZFSPV scheduler will schedule the PV among those nodes only.
+Note that if storageclass is using Immediate binding mode and storageclass allowedTopologies is not mentioned then all the nodes should be labeled using "ALLOWED_TOPOLOGIES" keys, that means, "ALLOWED_TOPOLOGIES" keys should be present on all nodes, nodes can have different values for those keys. If some nodes don't have those keys, then ZFSPV's default scheduler can not effectively do the volume capacity based scheduling. Here, in this case the CSI provisioner will pick keys from any random node and then prepare the preferred topology list using the nodes which has those keys defined and ZFSPV scheduler will schedule the PV among those nodes only.
 
 ### 7. Why the ZFS volume size is different than the reqeusted size in PVC