Hear Ye! Hear Ye! Trident 18.04 is available now!

Leaves are back on the trees, flowers are blooming, pollen is in the air! As the saying goes, April showers bring Trident releases, and we are very happy to announce that Trident 18.04 is now available! Take your allergy pill, change the oil in your lawn mower, and come see what’s new and exciting!

Completely new installer

That’s right, the Trident for Kubernetes installer has been completely rewritten to make it easier, more friendly to use, and it’s fully integrated with tridentctl.

  • Pre-validation! Before attempting to install Trident, or add a new backend, do a dry run to verify the backend configuration works!

    Uh-oh, I borked my password!

    Everything looks good, ready to deploy!

  • Previously a Trident for Kubernetes install was an automated but somewhat convoluted multi-step process which made troubleshooting complex. We had to answer the question of how to provision a persistent volume for the persistent volume provisioner. We did this by creating an ephemeral Trident deployment, which was used to provision that first volume. The new installer does this work directly:

    Simple. Easy. And, most importantly, it’s obvious what is happening. No more troubleshooting trident-launcher and trident-ephemeral!

Kubernetes 1.10 and OpenShift 3.9 are fully supported

Using the newest versions of Kubernetes or OpenShift? Great! We’ve got you covered! Trident 18.04 has been tested and validated with both of these platforms, which means it’s fully supported…if you have any problems, we’re here to help!

Custom backend names

That sounds completely unexciting, doesn’t it?

Oh look, I can call my backend “NetAppRox” if I want. Yawn.

It’s so much more exciting than that! Decoupling the name of the backend from the configuration enables you to have multiple, customized configurations for the same set of storage resources. Let’s look at some examples:

  • Want to have multiple backends using the same storage resources but with different snapshot policies? You can do that now!
  • Want to use different export policies or volume access groups to control access to storage resources from the same storage device? You can do that now!
  • Need some volumes to use encryption and others to be unencrypted on the same SVM? You can do that now!

Let’s dig into that first one a little bit. Being able to offer, through different storage classes, multiple data protection policies that still come from the same set of storage resources enables us to customize the offerings to applications, optimizing and balancing the resources consumed with the protection needed.

To accomplish our goal of having multiple snapshot policies for our storage array, we need three things:

  1. A backend which specifies the first snapshot policy:

  2. A backend which specifies the second snapshot policy:

  3. Storage classes for each backend which identify the protection policy. Notice that we provide the same storage pool list to both, but with different backend names.

With this configuration, our users can request storage which has a protection policy meeting their needs and enables them to recover data without having to wait for a storage admin! Neat!

That’s not all…

As always, there’s so many other amazing things which make it into each Trident release:

  • ONTAP: Management interfaces support DNS names – In 18.01 we introduced the ability to use the DNS name for data LIFs in the backend definition. This enabled several use cases around disaster recovery (e.g. SVM-DR without network identity retention) and performance (DNS load balancing), but still presented issues when trying to optimize connectivity to the management LIF.
  • SolidFire: CHAP improvements – In the last version we introduced the ability to use SolidFire CHAP instead of volume access groups to enable access to volumes. In 18.04 we’ve made this even easier by defaulting to CHAP for SolidFire backends, and, to improve security, we store the CHAP secret in the Trident namespace.
  • Updating backends is much easier – Want to rename your backends to something more friendly? It’s super easy using 18.04:

    The new config should contain all of the settings you want to keep, along with a new backendName value set. You can use this same command to update other properties of the backend, just remember that if you don’t set a property in the config file, Trident will unset that value.

Making great even better

18.04 is available now, so please upgrade as soon as you can to get access to all the great new features (and fixes)! As always, we’re interested in what you think and how your experience has been. Please leave us a comment below, reach out using Slack, or create an issue on our GitHub page.

We will also be at KubeCon, in Copenhagen, Denmark from May 2-5 as well as Red Hat Summit in San Francisco May 8-10. Please stop by our booths and say hello!

Andrew Sullivan on GithubAndrew Sullivan on Twitter
Andrew Sullivan
Technical Marketing Engineer at NetApp
Andrew has worked in the information technology industry for over 10 years, with a rich history of database development, DevOps experience, and virtualization. He is currently focused on storage and virtualization automation, and driving simplicity into everyday workflows.

Leave a Reply