Release notes
Known issues
Suggest changes
PDFs
Known issues identify problems that might prevent you from using this release of the product successfully.
The following known issues affect the current release:
-
Restore of an app results in PV size larger than original PV
-
App clones fail when using Service Account level OCP Security Context Constraints (SCC)
-
App clones fail after an application is deployed with a set storage class
-
App backups and snapshots fail if the volumesnapshotclass is added after a cluster is managed
Restore of an app results in PV size larger than original PV
If you resize a persistent volume after creating a backup and then restore from that backup, the persistent volume size will match the new size of the PV instead of using the size of the backup.
App clones fail using a specific version of PostgreSQL
App clones within the same cluster consistently fail with the Bitnami PostgreSQL 11.5.0 chart. To clone successfully, use an earlier or later version of the chart.
App clones fail when using Service Account level OCP Security Context Constraints (SCC)
An application clone might fail if the original security context constraints are configured at the service account level within the namespace on the OpenShift Container Platform cluster. When the application clone fails, it appears in the Managed Applications area in Astra Control Center with status Removed. See the knowledgebase article for more information.
App backups and snapshots fail if the volumesnapshotclass is added after a cluster is managed
Backups and snapshots fail with a UI 500 error in this scenario. As a workaround, refresh the app list.
App clones fail after an application is deployed with a set storage class
After an application is deployed with a storage class explicitly set (for example, helm install …-set global.storageClass=netapp-cvs-perf-extreme), subsequent attempts to clone the application require that the target cluster have the originally specified storage class.
Cloning an application with an explicitly set storage class to a cluster that does not have the same storage class will fail. There are no recovery steps in this scenario.
Managing a cluster with Astra Control Center fails when default kubeconfig file contains more than one context
You cannot use a kubeconfig with more than one cluster and context in it. See the knowledgebase article for more information.
Managed clusters do not appear in NetApp Cloud Insights when connecting through a proxy
When Astra Control Center connects to NetApp Cloud Insights through a proxy, managed clusters might not appear in Cloud Insights. As a workaround, run the following commands on each managed cluster:
kubectl get cm telegraf-conf -o yaml -n netapp-monitoring | sed '/\[\[outputs.http\]\]/c\ [[outputs.http]]\n use_system_proxy = true' | kubectl replace -f -kubectl get cm telegraf-conf-rs -o yaml -n netapp-monitoring | sed '/\[\[outputs.http\]\]/c\ [[outputs.http]]\n use_system_proxy = true' | kubectl replace -f -kubectl get pods -n netapp-monitoring --no-headers=true | grep 'telegraf-ds\|telegraf-rs' | awk '{print $1}' | xargs kubectl delete -n netapp-monitoring podApp data management operations fail with Internal Service Error (500) when Astra Trident is offline
If Astra Trident on an app cluster goes offline (and is brought back online) and 500 internal service errors are encountered when attempting app data management, restart all of the Kubernetes nodes in the app cluster to restore functionality.