Skip to main content
A newer release of this product is available.

Release Notes

Contributors juliantap
PDFs

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 in 21.10.1

NetApp is continually improving and enhancing its products and services. Here are some of the latest features and functionalities available in Astra Trident.

For previous releases, see Ealier versions of documentation.

Changes since Astra Trident 21.10.0

Warning The v21.10.0 release has an issue that can put the Trident controller into a CrashLoopBackOff state when a node is removed and then added back to the Kubernetes cluster. This issue is fixed in v21.10.1 (GitHub issue 669).

Fixes

  • Fixed potential race condition when importing a volume on a GCP CVS backend resulting in failure to import.

  • Fixed an issue that can put the Trident controller into a CrashLoopBackOff state when a node is removed and then added back to the Kubernetes cluster (GitHub issue 669).

  • Fixed issue where SVMs were no longer discovered if no SVM name was specified (GitHub issue 612).

Changes since Astra Trident 21.07

Fixes

  • Fixed issue where clones of XFS volumes could not be mounted on the same node as the source volume (GitHub issue 514).

  • Fixed issue where Astra Trident logged a fatal error on shutdown (GitHub issue 597).

  • Kubernetes-related fixes:

    • Return a volume's used space as the minimum restoreSize when creating snapshots with ontap-nas and ontap-nas-flexgroup drivers (GitHub issue 645).

    • Fixed issue where Failed to expand filesystem error was logged after volume resize (GitHub issue 560).

    • Fixed issue where a pod could get stuck in Terminating state (GitHub issue 572).

    • Fixed the case where an ontap-san-economy FlexVol might be full of snapshot LUNs (GitHub issue 533).

    • Fixed custom YAML installer issue with different image (GitHub issue 613).

    • Fixed snapshot size calculation (GitHub issue 611).

    • Fixed issue where all Astra Trident installers could identify plain Kubernetes as OpenShift (GitHub issue 639).

    • Fixed the Trident operator to stop reconciliation if the Kubernetes API server is unreachable (GitHub issue 599).

Enhancements

  • Added support for unixPermissions option to GCP-CVS Performance volumes.

  • Added support for scale-optimized CVS volumes in GCP in the range 600 GiB to 1 TiB.

  • Kubernetes-related enhancements:

    • Added support for Kubernetes 1.22.

    • Enabled the Trident operator and Helm chart to work with Kubernetes 1.22 (GitHub issue 628).

    • Added operator image to tridentctl images command (GitHub issue 570).

Experimental enhancements

  • Added support for volume replication in the ontap-san driver.

  • Added tech preview REST support for the ontap-nas-flexgroup, ontap-san, and ontap-nas-economy drivers.

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.

Find more information