************* Release Notes ************* =================================== Robin Cloud Native Platform v5.7.1 =================================== The Robin Cloud Native Platform (CNP) v5.7.1 release notes has pre- and post-upgrade considerations, fixed issues, and known issues. **Release Date:** February 23, 2026 Infrastructure Versions ======================= The following software applications are included in this CNP release: ==================== ================== Software Application Version ==================== ================== Kubernetes 1.33.5 Docker 25.0.2 (RHEL 8.10 or Rocky Linux 8.10) Podman 5.4.0 (RHEL 9.6) Prometheus 2.39.1 Prometheus Adapter 0.10.0 Node Exporter 1.4.0 Calico 3.28.2 HAProxy 2.4.7 PostgreSQL 14.12 Grafana 9.2.3 CRI Tools 1.33.0 cert-manager 1.19.1 ==================== ================== Supported Operating Systems =========================== The following are the supported operating systems and kernel versions for Robin CNP v5.7.1: ============================= ======================================= OS Version Kernel Version ============================= ======================================= Red Hat Enterprise Linux 8.10 4.18.0-553.el8_10.x86_64 Rocky Linux 8.10 4.18.0-553.el8_10.x86_64 Red Hat Enterprise Linux 9.6 5.14.0-570.24.1.el9_6.x86_64+rt ============================= ======================================= .. Note:: Robin CNP supports both RT and non-RT kernels on above supported operating systems. Upgrade Paths ============= The following are the supported upgrade paths for Robin CNP v5.7.1: * Robin CNP v5.4.3 HF5+PP to Robin CNP v5.7.1-311 * Robin CNP v5.4.3 HF6 to Robin CNP v5.7.1-311 * Robin CNP v5.4.3 HF7 to Robin CNP v5.7.1-311 * Robin CNP v5.5.1-1950 to Robin CNP v5.7.1-311 * Robin CNP v5.7.0-296 to Robin CNP v5.7.1-311 Pre-upgrade considerations -------------------------- * For a successful upgrade, you must run the ``possible_job_stuck.py`` script before and after the upgrade. Contact the Robin Support team for the upgrade procedure using the script. * When upgrading from supported Robin CNP versions to Robin CNP v5.7.1, if your cluster already has cert-manager installed, you must uninstall it before upgrading to Robin CNP v5.7.1. * Before upgrading to Robin CNP v5.7.1, you must stop the ``robin-certs-check`` job or CronJob. To stop the ``robin-certs-check`` job, run the ``kubectl delete job robin-certs-check -n robinio`` command, and to stop the ``robin-certs-check`` CronJob, run the ``robin cert check --stop-cronjob`` command. Post-upgrade considerations --------------------------- * After upgrading to Robin CNP v5.7.1, verify that the value of the ``k8s_resource_sync`` config parameter is set to ``60000`` using the ``robin schedule list | grep -i K8sResSync`` command. If it is not set, you must run the ``robin schedule update K8sResSync k8s_resource_sync 60000`` command to update the value of the ``robin schedule K8sResSync`` config parameter. * After upgrading to Robin CNP v5.7.1, you must run the ``robin-server validate-role-bindings`` command. To run this command, you need to log in to the ``robin-master`` Pod. This command verifies the roles assigned to each user in the cluster and corrects them if necessary. * After upgrading to Robin CNP v5.7.1, the ``k8s_auto_registration`` config parameter is disabled by default. The config setting is deactivated to prevent all Kubernetes apps from automatically registering and consuming resources. The following are the points you must be aware of with this change: - You can register the Kubernetes apps using the ``robin app register`` command manually and use Robin CNP for snapshots, clones, and backup operations of the Kubernetes app. - As this config parameter is disabled, when you run the ``robin app nfs-list`` command, the mappings between Kubernetes apps and NFS server Pods are not listed in the command output. - If you need mapping between Kubernetes app and NFS server Pod when the ``k8s_auto_registration config`` parameter is disabled or the k8s app is not manually registered, get the PVC name from the Pod YAML file ``(kubectl get pod -n -o YAML)`` and run the ``robin nfs export list | grep `` command. - The ``robin nfs export list`` command output displays the PVC name and namespace. * After upgrading to Robin CNP v5.7.1, you must start the ``robin-certs-check`` CronJob using the ``robin cert check -stat-cronjob`` command, if it was stopped before upgrade. Pre-upgrade steps ------------------ * **Upgrading from Robin CNP v5.4.3 to Robin CNP v5.7.1-311** Before upgrading from Robin CNP v5.4.3 HF5 to Robin CNP v5.7.1, perform the following steps: #. Update the value of the ``suicide_threshold`` config parameter to ``1800``: .. code-block:: text # robin config update agent suicide_threshold 1800 #. Verify the NFS monitor is enabled. It must be ``True`` .. code-block:: text # robin schedule list | grep -I NFS #. Set the toleration seconds for all NFS server Pods to ``86400`` seconds. After upgrade, you must change the tolerations seconds according to the post-upgrade steps. .. code-block:: text for pod in `kubectl get pod -n robinio -l robin.io/instance=robin-nfs --output=jsonpath={.items..metadata.name}`; do echo "Updating $pod tolerationseconds to 86400"; kubectl patch pod $pod -n robinio --type='json' -p='[{"op": "replace", "path": "/spec/tolerations/0/tolerationSeconds", "value": 86400}, {"op": "replace", "path": "/spec/tolerations/1/tolerationSeconds", "value": 86400}]'; done #. Verify the webhooks are enabled. .. code-block:: text # robin config list | grep -I robin_k8s_extension It must be ``True``. If it the disabled, enable it. .. code-block:: text # robin config update manager robin_k8s_extension True #. Check the mutating webhook’s is present on the cluster. .. code-block:: text # kubectl get mutatingwebhookconfiguration -A #. Enable ``robin_k8s_extension``. **Note**: You must create the ``robin-schedulextender-policy-template.yaml`` and ``preentry-.sh`` files in the ``usr/local/robin`` directory on all three K8s control-plane hosts. - Create a ``robin-schedulextender-policy-template.yaml`` file and add the following: .. code-block:: text apiVersion: kubescheduler.config.k8s.io/v1 kind: KubeSchedulerConfiguration clientConnection: kubeconfig: /etc/kubernetes/scheduler.conf extenders: - urlPrefix: "https://{{hostname}}:{{port}}/{{urlsuffix}}" filterVerb: predicates enableHTTPS: true nodeCacheCapable: false ignorable: {{ignorable}} httpTimeout: {{httptimeout}} tlsConfig: insecure: true managedResources: - name: robin.io/robin-required ignoredByScheduler: true - Create a ``preentry-.sh`` and add the following: .. code-block:: text # cp /usr/local/robin/robin-schedulextender-policy-template.yaml /opt/robin/current/etc/robin/k8s/robin-schedulextender-policy-template.yaml # cp /usr/local/robin/robin-schedulextender-policy-template.yaml /etc/robin/k8s/robin-schedulextender-policy-template.yaml * **Upgrading from Robin CNP v5.5.1 to Robin CNP v5.7.1-311** Before upgrading from Robin CNP v5.5.1 to Robin CNP v5.7.1, perform the following steps: #. Verify the NFS monitor is enabled using ``robin schedule list | grep -I NFS``. It must be ``True``. #. Update the value of the ``suicide_threshold`` config parameter to ``1800``: .. code-block:: text # robin config update agent suicide_threshold 1800 #. Set the toleration seconds for all NFS server Pods to ``86400`` seconds. After upgrade, you must change the tolerations seconds according to the post-upgrade steps. .. code-block:: text for pod in `kubectl get pod -n robinio -l robin.io/instance=robin-nfs --output=jsonpath={.items..metadata.name}`; do echo "Updating $pod tolerationseconds to 86400"; kubectl patch pod $pod -n robinio --type='json' -p='[{"op": "replace", "path":"/spec/tolerations/1/tolerationSeconds", "value": 86400}, {"op":"replace", "path": "/spec/tolerations/2/tolerationSeconds", "value":86400}]']; done Post-upgrade steps ------------------- * **After upgrading from Robin CNP v5.4.3 or Robin CNP v5.5.1 to Robin CNP v5.7.1-311** After upgrading from Robin CNP v5.4.3 or Robin CNP v5.5.1 to Robin CNP v5.7.1, perform the following steps: #. Update the value of the ``suicide_threshold`` config parameter to ``40``: .. code-block:: text # robin config update agent suicide_threshold 40 #. Set the ``check_helm_apps`` config parameter to ``False``: .. code-block:: text # robin config update cluster check_helm_apps False #. Set the ``chargeback_track_k8s_resusage`` config parameter to ``False``: .. code-block:: text # robin config update server chargeback_track_k8s_resusage False #. Set the ``robin_k8s_extension`` config parameter to ``True``. If no, set it to ``True``. .. code-block:: text # robin config update manager robin_k8s_extension True #. Verify whether the following mutating webhooks are present: .. code-block:: text # kubectl get mutatingwebhookconfigurations -A | grep robin k8srobin-deployment-mutating-webhook 1 20d k8srobin-ds-mutating-webhook 1 20d k8srobin-pod-mutating-webhook 1 20d k8srobin-sts-mutating-webhook 1 20d robin-deployment-mutating-webhook 1 20d robin-ds-mutating-webhook 1 20d robin-pod-mutating-webhook 1 20d robin-sts-mutating-webhook 1 20d #. If above ``k8srobin-*`` mutating webhooks are not present then bounce the ``robink8s-serverext`` Pods: .. code-block:: text # kubectl delete pod -n robinio -l app=robink8s-serverext #. Verify whether the following validating webhooks are present: .. code-block:: text # kubectl get validatingwebhookconfigurations NAME WEBHOOKS AGE cert-manager-webhook 1 45h controllers-validating-webhook 1 31h ippoolcr-validating-webhook 1 31h namespaces-validating-webhook 1 31h pods-validating-webhook 1 31h pvcs-validating-webhook 1 31h #. If ``robin-*`` mutating webhooks displayed in the step 6 output and validating webhooks displayed in the step 8 output are not present on your setup, then restart the ``robin-server-bg`` service: .. code-block:: text # rbash master # supervisorctl restart robin-server-bg #. Set the toleration seconds for all NFS server Pods to ``60`` seconds when the node is in the ``notready`` state and set to ``0`` seconds, when the node is ``unreachable`` state. .. code-block:: text for pod in `kubectl get pod -n robinio -l robin.io/instance=robin-nfs --output=jsonpath={.items..metadata.name}`; do echo "Updating $pod tolerationseconds"; kubectl patch pod $pod -n robinio --type='json' -p='[{"op": "replace", "path": "/spec/tolerations/0/tolerationSeconds", "value": 60}, {"op": "replace", "path": "/spec/tolerations/1/tolerationSeconds", "value": 0}]'; done 2>/dev/null Fixed Issues ============ ======================= ================================================================================================================================================================================================================================================================================================================================================================================================================================================================================ Reference ID Description ======================= ================================================================================================================================================================================================================================================================================================================================================================================================================================================================================ RSD-11129 The issue of allowing duplicate VLAN entries on a host interface in Robin CNP v5.7.0 is fixed. RSD-11117 When creating a VM on the OVS network using the ``robin app create from-bundle`` command, it is failing and resulting in the prevention of VM-based application deployment. This issue is fixed. RSD-11089 When rebooting the primary master node on the cluster caused the cluster to hang indefinitely due to the ``robin-vblock-clean`` process entering a D-state (uninterruptible sleep) due to an issue in ``tcmur_fake_handler``. This issue is fixed. RSD-11107 Pod with FPGA PCI resource requirements fails to deploy even when valid PCI devices are available on the host and displays the following FailedScheduling error: ``Insufficient intel.com/fpga_0000_1f_00_0_vfiopci``. This issue is fixed. PP-40940 Burstable Pods deployment fails with these types of errors: with "Insufficient CPU" or "No host found" errors if their total resource requests (CPU or huge pages) exceed the capacity of a single NUMA node while using a Robin IP pool. This issue is fixed. Robin CNP now allows burstable Pods to span multiple NUMA nodes, even when the ``topology_manager_policy`` is set to restricted. RSD-11042 The issue of the standby Robin master Pod failing its readiness probe and becoming unhealthy due to a mismatch between the in-memory phase state and the value stored in ``/etc/robin/robin_master/phase`` is fixed. RSD-11112 When creating a VM on the Calico network using the ``robin app create from-bundle`` command, it is failing and resulting in the prevention of VM-based application deployment. This issue is fixed. RSD-11179 The issue of adding a TLS-enabled LDAP server to a Robin CNP cluster failing due to use of the unsupported TLSv1 protocol is fixed. Robin CNP now uses the TLSv1_2 protocol, allowing the TLS layer to be configured properly. ======================= ================================================================================================================================================================================================================================================================================================================================================================================================================================================================================ Known Issues ============= ============= ============================================================================================================================================================================================================================================================================================================================================================================================================ Reference ID Description ============= ============================================================================================================================================================================================================================================================================================================================================================================================================ PP-41172 **Symptom** After upgrading from a supported Robin CNP version to Robin CNP v5.7.1, NFS mounts on client nodes can become unresponsive, leading to critical issues such as the following: * kubelet instability (frequent restarts) * patronictl command failures (connection refused) * kubectl exec operations failing for pods on affected nodes. This problem is primarily observed when the NFS client (the node where the PVC is mounted) experiences prolonged unresponsiveness from the NFS server. **Workaround** If an NFS mount is hung, you can recover the system by forcing new NFS sessions: 1. Identify hung NFS Mounts: * Attempt to access the NFS mount path. **Example** */var/lib/kubelet/pods//volumes/kubernetes.io~csi//mount.* * If the command hangs (for example, ``ls /path/to/mount`` with no output and requiring Ctrl+C to exit), the mount is hung. **Example** .. code-block:: text $ ls /var/lib/pods/0cab5468-b43f-4afd-bad3/volumes/ kubernetes.io~csi/pvc-7f31e2fc-b5b7-4991-ab97/mount^C 2. Confirm that the NFS export for the hung PVC is in a ``READY`` state using ``robin nfs export-list``. **Example** .. code-block:: text $ robin nfs export-list|grep pvc-7f31e2fc-b5b7-4991-ab97 |READY|19|pvc-7f31e2fc-b5b7-4991-ab97|robin-nfs-shared-23| ["sm-compute02"]|192.02.204.31:/pvc-7f31e2fc-b5b7-4991-ab97| loaddbehg-fio|sachin| 3. From the ``robin nfs export-list`` output, note the NFS Server Pod name serving the hung export. For example, in the above output, the NFS server Pod is ``robin-nfs-shared-23``. 4. Delete the identified NFS server pod. This action forces new NFS sessions and typically resolves the hung mount issue: .. code-block:: text # kubectl delete pod -n robinio **Example** .. code-block:: text # kubectl delete pod robin-nfs-shared-23 -n robinio PP-41195 **Symptom** After you perform a force unmount operation for an RWX (ReadWriteMany) volume on a host where it was previously mounted, or during certain failover scenarios involving RWX volumes, the associated Robin NFS server Pod might transition into an ASSIGNED_ERR state. When the Pod is in this state, the NFS server Pod is unable to export the volume, rendering the volume inaccessible via NFS. **Workaround** Contact the Robin Customer Support team to resolve this issue. PP-41192 **Symptom** When creating a KVM using the Robin bundle, CPU core count must be specified in even numbers. If odd numbers are specified, the KVM will not be deployed, however, the respective Pod might be in the ``Running`` state. PP-41159 **Symptom** After upgrading to Robin CNP v5.7.1, some Pods might get stuck in the ``ContainerCreating`` state because the VolumeUnmount job holds a lock on the volume, and the ``VolumeUnmount`` job shows the following error: *Target /var/lib/robin/nfs/robin-nfs-shared-107/ganesha/pvc-b84ed376-2a58-484f-8031-4530c1899b2c is busy, please retry later. (In some cases useful info about processes that use the device is found by lsof(8) or fuser(1))* **Workaround** Apply the following workaround steps: 1. Verify no pending I/Os at the RIO layer: .. code-block:: text # rio snapshot iolist 2. Verify no in-flight I/Os on the relevant block device: .. code-block:: text # /sys/block//inflight 3. If there are no pending and in-flight I/Os, do a lazy unmount with the path shown in the ``VolumeUnmount`` job error message: .. code-block:: text # umount -l PP-40988 In rare scenarios, after you perform an application upgrade on Robin CNP, the application's Pod might enter into a ``flapping`` state where it repeatedly restarts. However, after a few redeployments, the Pod becomes stable on its own without any intervention, and this behavior is intermittent. ============= ============================================================================================================================================================================================================================================================================================================================================================================================================ Technical Support ================= Contact `Robin Technical support `_ for any assistance.