ANOTHER UPDATE: Trident v21.07.1 is now available.
UPDATE: Users are informed that Trident v21.07.0 is NOT AVAILABLE FOR DOWNLOAD. Changes introduced to
snapshotReserve with v21.07.0 can result in CSI VolumeSnapshots being unusable to create PersistentVolumeClaim(s).
This will be fixed with v21.07.1. If you have already upgraded to v21.07.0, users are advised to delete newly created VolumeSnapshots (provisioned with v21.07.0) and downgrade to the previous release in use.
The birth of August is reason enough to be happy. Cooler temperatures are just around the corner (hopefully) and tennis fans are already counting down to the US Open. As always, there is one thing that I look forward to when August comes calling: a new release of Trident! This time is no different, with a bounty of new features and a name change to top it all off. Here’s the breakdown on everything v21.07, which can now be downloaded from our GitHub repository:
Namaste Astra Trident: With growth comes change, promising further progress and success. Trident is now officially a part of NetApp’s Astra portfolio and rebrands to Astra Trident. While this doesn’t change how users consume Trident, it announces Trident’s presence in the Astra stack; this is an important step towards providing Kubernetes data and storage management solutions that are feature-rich, natively consumable, and flexible. You can learn more about this by reading this blog.
With change comes uncertainty. There are several questions that users may have because of this modification. This non-exhaustive list covers the important ones. As always, you can reach out to the user community on Slack. We are here to help.
snapshotReserve is now smarter and better: Based on feedback from the community on how
snapshotReserve handles space allocation, an improved approach is now used for the
ontap-nas-flexgroup drivers. Astra Trident will now create a FlexVol that is larger than the size requested in the PVC, to account for metadata and provide a delta for snapshot reserve. This also means that users will now see the PVC’s size as the amount of writable space.
snapshotReserve shall henceforth represent the percentage of the total volume. The documentation discusses this in further detail.
Configurable capacity pools with Azure NetApp Files (ANF): ANF backend definitions can now take a list of capacity pools using the
capacityPools parameter. Earlier, capacity pools couldn’t be provided as part of a backend, restricting volume positioning. Astra Trident admins can now create multiple ANF backends for a subscription, picking and choosing the candidate capacity pools for each of them. This makes it even easier to target a specific set of capacity pools for volume allocation, and assists in grouping ANF volumes for multi-tenancy.
Enhancements to iSCSI drivers: As part of a continual effort to enhance the capability and efficiency of Astra Trident’s iSCSI drivers, this release includes functionality that improves the overall iSCSI experience. Multipathing has been one of those areas of focus. The Astra Trident recommendation for multipath configuration has changed. It is recommended that Astra Trident users review these changes, which can be found in the documentation.
CSI all the way: v21.07 introduces another momentous change: by bumping our minimum Kubernetes version floor up to 1.17, we bid goodbye to the good ol’ pre-CSI frontend of Trident that started it all off. Existing Trident installs that run pre-CSI (Kubernetes [1.11 – 1.13]) will need to upgrade their Kubernetes clusters to consume v21.07.
REST in peace – ONTAP REST support is here: Another opt-in feature that is a sign of the times, v21.07 includes support for ONTAP REST APIs as “tech-preview”. Trident admins can set
useREST to true for
ontap-nas backends today to instruct Trident to talk over REST instead of ZAPIs. This is not intended for production workloads and is a great way to understand how REST changes things. Users can give this a try on ONTAP 9.8+ clusters with a security role that has access to the
ontap application. This includes pre-defined
eseries-iscsi: Following in the footsteps of this announcement, the
eseries-iscsi storage driver has been disabled in the codebase. This is a decision that has been made based on systems-gathered telemetry and priorities determined by feedback from the existing user community. If you would like to use E/EF series clusters for Kubernetes workloads, fret not as there are options. Take a look at the upstream iSCSI driver and/or NetApp’s BeeGFS storage driver.
In the interest of keeping this blog crisp, there are several bug fixes and improvements that haven’t been highlighted. These can be found in the release notes.
Did someone raise their hand?
We are listening. Reach out to the user community and specialists in the #containers channel on our Slack workspace. Until next time!