From 416b336eb50785adfeb2dbbf57202777fa5df940 Mon Sep 17 00:00:00 2001 From: Boya Murthy Date: Wed, 17 Apr 2024 15:41:33 +0530 Subject: [PATCH] update the daemonset --- content/docs/csidriver/release/powermax.md | 2 +- content/v1/csidriver/release/powermax.md | 2 +- content/v2/csidriver/release/powermax.md | 2 +- content/v3/csidriver/release/powermax.md | 2 +- 4 files changed, 4 insertions(+), 4 deletions(-) diff --git a/content/docs/csidriver/release/powermax.md b/content/docs/csidriver/release/powermax.md index b7dcc0a0b0..cfdd3a6873 100644 --- a/content/docs/csidriver/release/powermax.md +++ b/content/docs/csidriver/release/powermax.md @@ -36,7 +36,7 @@ description: Release notes for PowerMax CSI driver | If the volume limit is exhausted and there are pending pods and PVCs due to `exceed max volume count`, the pending PVCs will be bound to PVs and the pending pods will be scheduled to nodes when the driver pods are restarted. | It is advised not to have any pending pods or PVCs once the volume limit per node is exhausted on a CSI Driver. There is an open issue reported with kubenetes at https://github.com/kubernetes/kubernetes/issues/95911 with the same behavior. | | Automatic SRDF group creation is failing with "Unable to get Remote Port on SAN for Auto SRDF" for PowerMaxOS 10.1 arrays | Create the SRDF Group and add it to the storage class | | [Node stage is failing with error "wwn for FC device not found"](https://github.com/dell/csm/issues/1070)| This is an intermittent issue, rebooting the node will resolve this issue | -| When the driver is installed using CSM Operator , few times, pods created using block volume are getting stuck in containercreating/terminating state or devices are not available inside the pod. | Update the damonset with parameter `mountPropagation: "Bidirectional"` for volumedevices-path under volumeMounts section.| +| When the driver is installed using CSM Operator , few times, pods created using block volume are getting stuck in containercreating/terminating state or devices are not available inside the pod. | Update the daemonset with parameter `mountPropagation: "Bidirectional"` for volumedevices-path under volumeMounts section.| ### Note: - Support for Kubernetes alpha features like Volume Health Monitoring and RWOP (ReadWriteOncePod) access mode will not be available in Openshift environment as Openshift doesn't support enabling of alpha features for Production Grade clusters. diff --git a/content/v1/csidriver/release/powermax.md b/content/v1/csidriver/release/powermax.md index 3fb7b90709..60bde1a5ad 100644 --- a/content/v1/csidriver/release/powermax.md +++ b/content/v1/csidriver/release/powermax.md @@ -43,7 +43,7 @@ description: Release notes for PowerMax CSI driver | If the volume limit is exhausted and there are pending pods and PVCs due to `exceed max volume count`, the pending PVCs will be bound to PVs and the pending pods will be scheduled to nodes when the driver pods are restarted. | It is advised not to have any pending pods or PVCs once the volume limit per node is exhausted on a CSI Driver. There is an open issue reported with kubenetes at https://github.com/kubernetes/kubernetes/issues/95911 with the same behavior. | | Automatic SRDF group creation is failing with "Unable to get Remote Port on SAN for Auto SRDF" for PowerMaxOS 10.1 arrays | Create the SRDF Group and add it to the storage class | | [Node stage is failing with error "wwn for FC device not found"](https://github.com/dell/csm/issues/1070)| This is an intermittent issue, rebooting the node will resolve this issue | -| When the driver is installed using CSM Operator , few times, pods created using block volume are getting stuck in containercreating/terminating state or devices are not available inside the pod. | Update the damonset with parameter `mountPropagation: "Bidirectional"` for volumedevices-path under volumeMounts section.| +| When the driver is installed using CSM Operator , few times, pods created using block volume are getting stuck in containercreating/terminating state or devices are not available inside the pod. | Update the daemonset with parameter `mountPropagation: "Bidirectional"` for volumedevices-path under volumeMounts section.| ### Note: - Support for Kubernetes alpha features like Volume Health Monitoring and RWOP (ReadWriteOncePod) access mode will not be available in Openshift environment as Openshift doesn't support enabling of alpha features for Production Grade clusters. diff --git a/content/v2/csidriver/release/powermax.md b/content/v2/csidriver/release/powermax.md index b808eade9e..c6a29b8244 100644 --- a/content/v2/csidriver/release/powermax.md +++ b/content/v2/csidriver/release/powermax.md @@ -34,7 +34,7 @@ description: Release notes for PowerMax CSI driver | Unable to update Host: A problem occurred modifying the host resource | This issue occurs when the nodes do not have unique hostnames or when an IP address/FQDN with same sub-domains are used as hostnames. The workaround is to use unique hostnames or FQDN with unique sub-domains| | When a node goes down, the block volumes attached to the node cannot be attached to another node | This is a known issue and has been reported at https://github.com/kubernetes-csi/external-attacher/issues/215. Workaround:
1. Force delete the pod running on the node that went down
2. Delete the volumeattachment to the node that went down.
Now the volume can be attached to the new node | | If the volume limit is exhausted and there are pending pods and PVCs due to `exceed max volume count`, the pending PVCs will be bound to PVs and the pending pods will be scheduled to nodes when the driver pods are restarted. | It is advised not to have any pending pods or PVCs once the volume limit per node is exhausted on a CSI Driver. There is an open issue reported with kubenetes at https://github.com/kubernetes/kubernetes/issues/95911 with the same behavior. | -| When the driver is installed using CSM Operator , few times, pods created using block volume are getting stuck in containercreating/terminating state or devices are not available inside the pod. | Update the damonset with parameter `mountPropagation: "Bidirectional"` for volumedevices-path under volumeMounts section.| +| When the driver is installed using CSM Operator , few times, pods created using block volume are getting stuck in containercreating/terminating state or devices are not available inside the pod. | Update the daemonset with parameter `mountPropagation: "Bidirectional"` for volumedevices-path under volumeMounts section.| ### Note: - Support for Kubernetes alpha features like Volume Health Monitoring and RWOP (ReadWriteOncePod) access mode will not be available in Openshift environment as Openshift doesn't support enabling of alpha features for Production Grade clusters. diff --git a/content/v3/csidriver/release/powermax.md b/content/v3/csidriver/release/powermax.md index df2810dc45..57a0ead4a2 100644 --- a/content/v3/csidriver/release/powermax.md +++ b/content/v3/csidriver/release/powermax.md @@ -31,7 +31,7 @@ There are no fixed issues in this release. |-------|------------| | Unable to update Host: A problem occurred modifying the host resource | This issue occurs when the nodes do not have unique hostnames or when an IP address/FQDN with same sub-domains are used as hostnames. The workaround is to use unique hostnames or FQDN with unique sub-domains| | When a node goes down, the block volumes attached to the node cannot be attached to another node | This is a known issue and has been reported at https://github.com/kubernetes-csi/external-attacher/issues/215. Workaround:
1. Force delete the pod running on the node that went down
2. Delete the volumeattachment to the node that went down.
Now the volume can be attached to the new node | -| When the driver is installed using CSM Operator , few times, pods created using block volume are getting stuck in containercreating/terminating state or devices are not available inside the pod. | Update the damonset with parameter `mountPropagation: "Bidirectional"` for volumedevices-path under volumeMounts section.| +| When the driver is installed using CSM Operator , few times, pods created using block volume are getting stuck in containercreating/terminating state or devices are not available inside the pod. | Update the daemonset with parameter `mountPropagation: "Bidirectional"` for volumedevices-path under volumeMounts section.| ### Note: