Contributors Download PDF of this page
Release Notes provide information about new features, enhancements, and bug fixes in the latest version of Astra Trident.
NetApp is continually improving and enhancing its products and services. Here are some of the latest features and functionalities available with Astra Trident.
Astra Trident 21.07.02
Fixed issue where clones of XFS volumes could not be mounted on the same node as the source volume.
Added support for Kubernetes 1.22.
Enabled the Trident operator and Helm chart to work with Kubernetes 1.22.
Astra Trident 21.07.01
Fixed custom YAML installer issue with different image.
Fixed snapshot size calculation issue.
Astra Trident 21.07
Astra Trident 21.07.0 is not available for download. Changes introduced to
snapshotReserve with version 21.07.0 can result in CSI
VolumeSnapshots being unusable for creating PersistentVolumeClaim(s).
If you have already upgraded to version 21.07.0, it is recommended that you delete the newly created
VolumeSnapshots (provisioned with version 21.07.0) and downgrade to the previous release.
Known issues identify problems that might prevent you from using the product successfully.
Astra Trident now enforces a blank
fsType="") for volumes that do not have the
fsTypespecified in their StorageClass. When working with Kubernetes 1.17 or later, Trident supports providing a blank
fsTypefor NFS volumes. For iSCSI volumes, you are required to set the
fsTypeon your StorageClass when enforcing an
fsGroupusing a Security Context.
When using a backend across multiple Astra Trident instances, each backend configuration file should have a different
storagePrefixvalue for ONTAP backends or use a different
TenantNamefor SolidFire backends. Astra Trident cannot detect volumes that other instances of Astra Trident have created. Attempting to create an existing volume on either ONTAP or SolidFire backends succeeds, because Astra Trident treats volume creation as an idempotent operation. If
TenantNamedo not differ, there might be name collisions for volumes created on the same backend.
When installing Astra Trident (using
tridentctlor the Trident Operator) and using
tridentctlto manage Astra Trident, you should ensure the
KUBECONFIGenvironment variable is set. This is necessary to indicate the Kubernetes cluster that
tridentctlshould work against. When working with multiple Kubernetes environments, you should ensure that the
KUBECONFIGfile is sourced accurately.
To perform online space reclamation for iSCSI PVs, the underlying OS on the worker node might require mount options to be passed to the volume. This is true for RHEL/RedHat CoreOS instances, which require the
discardmount option; ensure that the discard mountOption is included in your
StorageClassto support online block discard.
If you have more than one instance of Astra Trident per Kubernetes cluster, Astra Trident cannot communicate with other instances and cannot discover other volumes that they have created, which leads to unexpected and incorrect behavior if more than one instance runs within a cluster. There should be only one instance of Astra Trident per Kubernetes cluster.
If Astra Trident-based
StorageClassobjects are deleted from Kubernetes while Astra Trident is offline, Astra Trident does not remove the corresponding storage classes from its database when it comes back online. You should delete these storage classes using
tridentctlor the REST API.
If a user deletes a PV provisioned by Astra Trident before deleting the corresponding PVC, Astra Trident does not automatically delete the backing volume. You should remove the volume via
tridentctlor the REST API.
ONTAP cannot concurrently provision more than one FlexGroup at a time unless the set of aggregates are unique to each provisioning request.
When using Astra Trident over IPv6, you should specify
dataLIFin the backend definition within square brackets. For example,
If using the
solidfire-sandriver with OpenShift 4.5, ensure that the underlying worker nodes use MD5 as the CHAP authentication algorithm.