20. Release Notes

20.1. Robin Cloud Native Storage v5.4.12-34

The Robin CNS v5.4.12-34 Release Notes document provides information about upgrade paths, new feature, improvements, and one known issue.

20.1.1. Upgrade paths

The following are the supported upgrade paths for Robin CNS v5.4.12-34:

  • Robin CNS v5.4.10-61 to Robin CNS v5.4.12-34

  • Robin CNS v5.4.8-280 to Robin CNS v5.4.12-34

  • Robin CNS v5.4.8-313 to Robin CNS v5.4.12-34

  • Robin CNS v5.4.4-182 to Robin CNS v5.4.12-34

Note

  • If you are upgrading from Robin CNS v5.4.4-182 to Robin CNS v5.4.12-34, you must stop any snapshot creation and deletion operations. However, in unavoidable situations, you can run the robin volume-snapshot upgrade --wait command post-upgrade.

  • After upgrading to Robin CNS v5.4.12-34, 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 v5.4.12-34.

20.1.2. New Features

20.1.2.1. Robin Master Pod in HA Mode

Starting from Robin CNS v5.4.12, the robin-master Pod is available in HA mode. The robin-master Pods are deployed as a Deployment. Depending on the number of nodes in the cluster, the robin-master Pods can range from a minimum of one for a single-node cluster to a maximum of three.

Note

If you utilize the master_node_selector parameter in the robin.yaml file, you need to label the nodes where you want the robin-master Pods to be scheduled. The number of robin-master Pods will be scheduled on the designated nodes accordingly. For example, if a cluster has two nodes matching the master node selector, there will be two robin-master Pods deployed.

If there are three robin-master Pod replicas, only one of the Pods play the role of the Master, and the remaining robin-master Pods takes the Standby role. Robin CNS uses the Kubernetes Lease mechanism to manage the Master role. This enhancement also addresses the Robin mount unavailability issue. For more information, see High Availability of the Robin control plane.

20.1.3. Improvements

20.1.3.1. Two Replicas for Robin CSI Pods

Starting from Robin CNS v5.4.12, there are two replicas for the Robin CSI provisioner, attacher, resizer, and snapshotter Pods. Having two replicas reduces the time window of unavailability of CSI pods if any node goes down.

20.1.3.2. Support to update additional Robin config attributes using robin-config ConfigMap

Starting from Robin CNS v5.4.12, you can update the suicide_threshold attribute of agent section using the robin-config ConfigMap. You can also update the attributes of the following Robin configuration sections using the robin-config ConfigMap:

  • agent

  • app

  • client

  • gui

  • database

  • database_storage

  • dr

  • event_server

  • file_server

  • host

  • manager

  • monitor_server

  • notification

  • user_audit

  • vip_info

  • auth_server

  • cloud

  • sherlock

20.1.4. Known Issues

Reference ID

Description

PP-35171

In rare scenarios, when upgrading to Robin CNS v5.4.12 from a supported version, the upgrade might not progress as the postgres-operator is stuck and marks the PostgreSQL CR in the SyncFailed state. You can verify and resolve the issue by following the workaround steps:

  1. Check if PostgreSQL CR is in the SyncFailed state if the upgrade is stuck by running the following command:

    # kubectl get postgresql -n robinio

  2. Grep for the postgres-operator Pod:

    # kubectl get pods -n robinio | grep postgres-operator

  3. Bounce the postgres-operator Pod:

    # kubectl delete pod <robin-patroni-postgres-operator-name>
-n robinio

    Example:

    # kubectl delete pod robin-patroni-postgres-operator-76cf684b78-lncdl
-n robinio
pod "robin-patroni-postgres-operator-76cf684b78-lncdl" deleted

20.1.5. Technical Support

Contact Robin Technical support for any assistance.