20. Release Notes

20.1. Robin Cloud Native Storage v6.1.1

20.1.1. Robin CNS v6.1.1 Release Notes

The Robin CNS v6.1.1-1 Release Notes document provides information about upgrade path, an improvement, a fixed issue, and known issues.

Release Date: June 11, 2026

20.1.2. Upgrade Path

The following is the supported upgrade path for Robin CNS v6.1.1-1:

• Robin CNS v5.4.18-257 to Robin CNS v6.1.1-1

• Robin CNS v6.0.0-226 to Robin CNS v6.1.1-1

Note

• After upgrading to Robin CNS v6.1.1-1, if you are using the Robin Client outside the robincli pod, you must upgrade to the latest version of the Robin Client.

• If you have installed Robin CNS with the skip_postgres_operator parameter to use the Zalando PostgreSQL operator, then you must first upgrade the Zalando PostgreSQL operator to v1.11.0 or later before upgrading to Robin CNS v6.1.1-1.

• After upgrading from any supported Robin CNS version, starting with Robin CNS v5.4.18, certificates will be automatically renewed.

20.1.3. Improvement

20.1.3.1. Added custom configuration support for Robin Patroni Monitor deployment

Starting with Robin CNS v6.1.1, Robin CNS supports the custom configuration for the robin-patroni-monitor deployment through the custom_config section in the robin.yaml file (RobinCluster CRD).

With this enhancement, you can configure the following settings for the robin-patroni-monitor pod:

• Node selectors: Control which nodes the Patroni Monitor pods are scheduled on.

• Tolerations: Allow scheduling on tainted nodes.

• Pod security context: Define pod-level security settings.

• Container resource requests and limits: Set CPU and memory boundaries for the patroni-monitor container.

• Container security context: Apply container-level security policies.

Sample custom configuration

The following is the custom_config section for the robin-patroni-monitor deployment:

# robin-patroni-monitor:
  # node_selector:
    # NODE_SELECTOR
  # tolerations:
    # TOLERATIONS
  # security_context:
    # POD_SECURITY_CONTEXT
  # containers:
    # patroni-monitor:
      # resources:
        # limits:
          # cpu: <cpu_limits>
          # memory: <memory_limits>
        # requests:
          # cpu: <cpu_requests>
          # memory: <memory_requests>
      # security_context:
        # CONTAINER_SECURITY_CONTEXT

20.1.4. Fixed Issue

Reference ID	Description
PP-42776	When upgrading from Robin CNS v5.4.18 to Robin CNS v6.1.0, the migration webhook was not correctly configured as per the API conversion strategy (from v1 to v2) in the RobinCluster CRD. This issue is fixed.

20.1.5. Known Issues

Reference ID	Description
PP-40480	Symptom In a rare scenario, you might observe that one of the Pods is stuck in the ContainerCreating state, and the kubectl describe pod command shows the following volume mount error: Failed to mount volume pvc-d16fa6b1-5bcb-4c69-805d-ab4df9018cee: Node <default:vnode-87-237> has mount_blocked STORMGR_NODE_BLOCK_MOUNT. No new mounts are allowed. Workaround Bounce the worker Pod running on the affected node.
PP-39632	Symptom After upgrading to Robin CNS v6.1.1, NFS client might hang with no pending IO message. For no pending IO, refer this path : /var/log/robin/nodeplugin/robin-csi.log with the following message: CsiServer_9 - robin.utils - INFO - Executing command /usr/bin/nc -z -w 6 2049 with timeout 60 seconds CsiServer_9 - robin.utils - INFO - Command /usr/bin/nc -z -w 6 2049 completed with return code 0. CsiServer_9 - robin.utils - INFO - Standard out: Also, you can find the following message in the dmesg: nfs: server 192.02.1.218 not responding, timed out nfs: server 192.02.1.218 not responding, timed out nfs: server 192.02.1.218 not responding, timed out Workaround Check the node provisioner logs where the PVC is checking for the path and it is hung. For the deployment/statefulset that is using the problematic PVC, scale down the replica count to 0. Ensure all Pods associated with the application have terminated. Scale up the replica count back to the original value.
PP-42418	Symptom If you try to delete a volume snapshot after a failed clone operation, the kubectl delete volumesnapshot command might hang indefinitely. This issue occurs because the Kubernetes finalizer provisioner.storage.kubernetes.io/volumesnapshot-as-source-protection isn’t removed if the associated Persistent Volume Claim (PVC) is deleted while in an unbound or unprovisioned state. Make sure that you have already deleted the underlying snapshot in Robin. When this issue occurs, the following warning appears: Snapshot is being used to restore a PVC. Workaround To delete the snapshot, manually remove the finalizer by following these steps: Remove the finalizer from the snapshot by running the following command: # kubectl patch volumesnapshot <snapshot_name> \ -p '{"metadata":{"finalizers":[]}}' \ --type=merge Replace snapshot_name with the name of your snapshot. Delete the snapshot: # kubectl delete volumesnapshot <snapshot_name> -n <namespace>
PP-34414	Symptom In a rare scenario, the IOMGR service might fail to open devices in the exclusive mode when it starts as other processes are using these disks. You might observe the following issues: All app Pods restart, and some app Pods get stuck in the ContainerCreating state. To confirm the above issues, complete the following steps: Check for the EVENT_DISK_FAULTED event type in the disk events: # robin event list --type EVENT_DISK_FAULTED If you see the disk is faulted error, check the IOMGR logs for dev_open() error and Failed to exclusively open message on the node where disks are present. # cat iomgr.log.0 | grep <device> | grep "dev_open" If you see the Device or resource busy error in the log file, use fuser command with the device path to confirm whether the device is in use: # fuser /dev/disk/by-id/scsi-SATA_Micron_M500_MTFD_1401096049D5 Workaround If the device is not in use, restart the IOMGR service on the respective node: # supervisorctl restart iomgr-server
PP-42723	Symptom During the Robin CNS v6.1.1 installation process, the robin-patroni-pre-install-hook Pod might go into the Pending state and the installation gets stuck. If you observe this issue, apply the following workaround. Workaround Check the robin-operator logs for the following message: Failed to deploy patroni helm chart. Find the node that has the patroni-pre-install-hook. # kubectl get node -l=patroni-pv-node=true Identify which node is hosting the robin-patroni-pre-install-hook Pod that is stuck in the Pending status. # kubectl get pods -n robinio | grep pre-install Run the following command to remove the has-run-patroni-pre-install-job label on the node associated with the pending Pod to allow it to reschedule. # kubectl label node <node-name> has-run-patroni-pre-install-job-
PP-42666	Symptom When you try to expand a volume, a discrepancy can occur where the Kubernetes API reports a successful resize, but the actual block device or file system inside the Pod remains at the original size. This issue typically occurs during mounted volume operations under conditions of storage timeouts or network instability. If you observe this issue, you can apply the following workarounds based on the volume type. Workaround RWX volume resize for file system volumes If a ReadWriteMany (RWX) volume expansion fails or fails to update the filesystem size inside the pod despite a successful Kubernetes resize, follow these steps to manually update the volume: Identify the PersistentVolumeClaim (PVC) name. # kubectl describe pod <application-pod> Find the actual volume name associated with the PVC. # kubectl get pvc <pvc-name> Locate the NFS server pod name. # robin nfs export-list Cordon the node that is running the NFS server pod. # kubectl cordon <node-name> Restart the NFS server Pod by deleting it. # kubectl delete pod <nfs-server-pod> Restart the application Pod by deleting it. # kubectl delete pod <application-pod> Uncordon the node that you cordoned in step 4. # kubectl uncordon <node-name> Edit your PVC YAML file and increase the volume size by 1GB more than your initial size. (For example, if you were trying to increase the volume size to 5GB initially, now increase it to 6GB.) Apply the PVC YAML file. # kubectl apply -f <your-pvc-file.yaml> Run lsblk to check the updated size. RWO volume resize for file system volumes If a ReadWriteOnce (RWO) file system volume expansion fails or fails to update the filesystem size inside the pod despite a successful Kubernetes resize, follow these steps to manually update the volume: Cordon the node where the volume is mounted: # kubectl cordon <node-name> Bounce the application Pod. # kubectl delete pod <app-pod-name> Uncordon the node that you cordoned in step 1. # kubectl uncordon <node-name> Identify the PVC/volume name. Find the PVC claim name. # kubectl describe pod <pod-name> Find the volume name. # kubectl get pvc <claim-name> Edit your PVC YAML file and increase the volume size by 1GB more than your initial size. (For example, if you were trying to increase the volume size to 5GB initially, now increase it to 6GB.) Apply the PVC YAML file. # kubectl apply -f <your-pvc-file.yaml> Verify the updated size inside the application Pod. # kubectl exec -it <app-pod-name> -- df -Th RWO volume resize for block volumes If a ReadWriteOnce (RWO) block volume expansion fails or fails to update the filesystem size inside the Pod despite a successful Kubernetes resize, follow these steps to manually update the volume: Cordon the node where the volume is mounted. # kubectl cordon <node-name> Bounce the application Pod. # kubectl delete pod <app-pod-name> Uncordon the node that you cordoned in step 1. # kubectl uncordon <node-name> Run lsblk to check the updated size.

20.1.6. Technical Support

Contact Technical support for any assistance.