Known issues identify problems that might prevent you from using this release of the product successfully.
The following known issues affect the current release:
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.
Applications page loads forever when trying to restore an application belonging to a deleted cluster
When you try to restore an app from a deleted cluster from the Applications page, the Applications page never finishes loading. As a workaround, restore the app from the app’s Actions menu in the Applications listing page.
Unable to define an app on a namespace that has been deleted and recreated
If you define an application with a namespace, delete the namespace, and then reinstall the app in the same namespace, the operation fails with a 409 error code. To define the app using the recreated namespace, delete the old application instance first.
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 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.
Azure backup buckets use LRS redundancy by default
By default, the buckets Astra Control Service uses to store Azure Kubernetes Service backups use the Locally Redundant Storage (LRS) redundancy option. To use a more durable redundancy option for Azure buckets, see the optional steps in the Azure cloud provider setup instructions:
Snapshots eventually begin to fail when using external-snapshotter version 4.2.0
When you use Kubernetes snapshot-controller (also known as external-snapshotter) version 4.2.0 with Kubernetes 1.20 or 1.21, snapshots can eventually begin to fail. To prevent this, use a different supported version of external-snapshotter, such as version 4.2.1, with Kubernetes versions 1.20 or 1.21.
App 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.