CSI 2.2.0 release notes (#321)

* Release notes for v2.1.1

Signed-off-by: Pavan Shanbhag <[email protected]>

* Fixed version numbers

Signed-off-by: Pavan Shanbhag <[email protected]>

* Fixed version numbers

Signed-off-by: Pavan Shanbhag <[email protected]>

* Addressed review comments

Signed-off-by: Pavan Shanbhag <[email protected]>

* Release notes for CSI 2.2.0

* Update for CON-2856

* Verbatim fix

* Addressed review comments.

* Removed quotes

Co-authored-by: Pavan Shanbhag <[email protected]>

release-notes/v2.2.0.md

@@ -0,0 +1,39 @@
+# HPE CSI Driver for Kubernetes 2.2.0 Release Notes
+
+## HPE CSI Driver for Kubernetes 2.2.0
+
+| **Version:** |2.2.0|
+|--------------|-----|
+| **Revision:** | Thursday July 20, 2022 |
+
+## Resolved Issues
+`
+The following table lists the resolved issues for HPE CSI Driver for Kubernetes v2.2.0.
+
+|ID|Component |Title|Resolution|
+|--|---------|-----|-----------|
+|CON-2149|csi.k8s|Custom taints : If the node has custom taint, the hpe-csi-node pod would not run on that node|A new feature has been added to address this; the user can now configure labels, tolerations, affinity and node selector's for the HPE CSI pod categories namely - Container Service Provider (CSPs), HPE CSI Node driver (hpe-csi-node) and HPE CSI Driver (hpe-csi-controller).|
+|CON-2295|csi.k8s|Multipath configuration: 3PAR/Primera/Alletra 9000 multipathing configurations do not consistently write multipathing recommendations to multipath.conf| The inconsistency existed in a situation where in, if a user already has multipath.conf tuned with their own settings or no settings,  the recommended multipath configurations, that the HPE CSI Node driver has knowledge of, are not propogated to multipath.conf. The second issue was that the 3PAR/Alletra family of arrays have recommended/tested multipathing configurations, and are specific to the OS distribution, where as, the current implementation did not account for distribution specific recommendations. This was a new feature that got implemented as part of this.|
+|CON-2736|csi.k8s|Volume expansion for an encrypted PVC fails for RH OS 8.x and higher|The volume expansion for the csi driver on RH OS 8.x and higher requires the encryption secret to be supplied. There is a constraint in supporting this as the CSI spec 1.3 does not allow for encryption secret for NodeExpandVolume operation. As a intermediate measure, we support LUKS1 encryption only with CSI driver 2.2.0 for now, which does not mandate the encryption secret. This also requires conversion of existing LUKS2 encrypted volumes to LUKS1 by following the procedure in SCOD|
+
+The following table lists the resolved issues for HPE Alletra 9000 and Primera/3PAR CSP for HPE CSI Driver release 2.2.0.
+
+|ID|Component |Title|Resolution|
+|--|---------|-----|-----------|
+|CON-2642|csi.k8s|Duplicate LUN Creation : When a PVC is attached to a pod, occasionally the CSI driver creates duplicate LUN's for the same PVC,Host,port combination| If the array is busy, and rejects LUN creation requests from CSP, a retry did not track whether the LUN is created, but triggered another LUN creation call (hence duplication). Now, we query what LUN's are already created and only retry the subset.|
+|CON-2166|csi.k8s|Cloning from Primera or 3PAR Snapshot deletes the snapshot in the array .|The CSP's cloning process with PVC as a source is to first create an intermediate snapshot, then create a clone using that intermediate snapshot as the source and then delete the intermediate snapshot. This process has a side-effect of deleting the snapshot always (a bug ), because CSP does not check whether the snaphost was user created or CSI generated intermediate snapshot. Now the fix adds that check.|
+
+## Known Issues
+
+The following table lists the known issues for HPE CSI Driver for Kubernetes v2.2.0. Please note that, `Known Issues` from previous releases are still applicable with suggested workarounds, if they are not part of `Resolved Issues` above.
+
+|ID|Component |Title|Description|Workaround|
+|--|---------|-----|-----------|----------|
+|CON-2643|csi.k8s|Pod remains in "ContainerCreating" state with the error "CSI Multi-attach error : Volume is already used by another pod"|The issue is that when a pod is force deleted (force deleted by user, because the pod gets stuck in terminating state due to kubelet being down on that node), there is a chance of the mount paths on the node getting corrupted, and the next time the same pod gets scheduled to run on the node, it does not start due to corrupted mount.|Fixing this in code could cause other anomalies and the recommendation here is to reboot the node. This provides a chance for the CSI Node driver to clean up mount points and fix this problem.|
+|CON-2856|csi.k8s|NFS failover: The pods using NFS volumes(clients) cannot perform I/O when the NFS server pod fails over to another node.|There seems to be stability issues with flannel CNI, due to which this issue shows up.|When we tested this with Calico CNI we do not see this issue, so if this issue is seen in any deployment, one solution is to use Calico CNI.|
+
+The following table lists the known issues for HPE Alletra 9000 and Primera/3PAR CSP for HPE CSI Driver release 2.2.0
+
+|ID|Component |Title|Description|Workaround|
+|--|---------|-----|-----------|----------|
+