Skip to main content
Astra Trident
21.07

Release Notes

Contributors

Release Notes provide information about new features, enhancements, and bug fixes in the latest version of Astra Trident.

Warning The tridentctl binary for Linux that is provided in the installer zip file is the tested and supported version. Be aware that the macos binary provided in the /extras part of the zip file is not tested or supported.

What's new

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.

Enhancements

  • Added support for Kubernetes 1.22.

  • Enabled the Trident operator and Helm chart to work with Kubernetes 1.22.

See Astra Trident GitHub for more information.

Astra Trident 21.07.01

  • Fixed custom YAML installer issue with different image.

  • Fixed snapshot size calculation issue.

See Astra Trident GitHub for more information.

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.

See Astra Trident GitHub for more information.

Known issues

Known issues identify problems that might prevent you from using the product successfully.

  • Astra Trident now enforces a blank fsType (fsType="") for volumes that do not have the fsType specified in their StorageClass. When working with Kubernetes 1.17 or later, Trident supports providing a blank fsType for NFS volumes. For iSCSI volumes, you are required to set the fsType on your StorageClass when enforcing an fsGroup using a Security Context.

  • When using a backend across multiple Astra Trident instances, each backend configuration file should have a different storagePrefix value for ONTAP backends or use a different TenantName for 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 storagePrefix or TenantName do not differ, there might be name collisions for volumes created on the same backend.

  • When installing Astra Trident (using tridentctl or the Trident Operator) and using tridentctl to manage Astra Trident, you should ensure the KUBECONFIG environment variable is set. This is necessary to indicate the Kubernetes cluster that tridentctl should work against. When working with multiple Kubernetes environments, you should ensure that the KUBECONFIG file 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 discard mount option; ensure that the discard mountOption is included in your StorageClass to 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 StorageClass objects 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 tridentctl or 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 tridentctl or 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 managementLIF and dataLIF in the backend definition within square brackets. For example, [fd20:8b1e:b258:2000:f816:3eff:feec:0].

  • If using the solidfire-san driver with OpenShift 4.5, ensure that the underlying worker nodes use MD5 as the CHAP authentication algorithm.