Trident: Feature request: reuse volumes

[dxlr8r]

I would like the ability to reuse an existing volume, that be qtrees or not, also for the temporary backend (installation). I currently target ONTAP NetApps, and we have our own naming and security standards, so having one or more volumes with random generated names and export-policies isn't a good option for us.

So instead of just "storagePrefix" there would also be for example a "storage" parameter. And trident would use that volume.

[kangarlou]

@dxlr8r Please elaborate what you mean by "temporary backend (installation)". Also, what's the purpose of the "storage" parameter and how will it be used?

Trident volumes names are made of storagePrefix, PVC namespace, PVC name, and a portion of the PVC UUID. Changing the naming scheme can potentially cause a lot of security problems where users in a different namespaces can access each others' volumes.

[kangarlou]

I should also note that Trident does allow setting the volume name for the volume that it internally uses (the one that is provisioned by Trident installer). To change this volume name, you should set the -volume_name parameter in launcher-pod.yaml. This file is shipped as part of the Trident installer bundle. Volume creation in Trident is an idempotent operation, so if the volume already exists, it will be reused by Trident. As an admin, this is the volume that you should care about the most. It's unclear to me how imposing a naming convention for the dynamically provisioned volumes (the ones created by users, not admins) results in a better security practice.

[dxlr8r]

I'm talking about the volume as in:

dirname /trident_qtree_pool_{storagePrefix}_{random}/{storagePrefix}_{pvc-ns}_{pvc}_{pvc-uuid}

I want to reuse a qtree, but haven't seen any options for specifing what qtree volume I want to use.

Something like this: /{storage}/{storagePrefix}_{pvc-ns}_{pvc}_{pvc-uuid}

[kangarlou]

If you want to reuse/share a qtree (or any other volume that Trident provisions), you should reuse the PVC that corresponds to that qtree. Considering PVCs are scoped to namespaces, you should be careful that the pods that are going to share a PVC are created in the same namespace.

[clintonk]

Hello, @dxlr8r. Thanks for the request, and we will consider it. Please keep in mind that the qtree driver manages the complete lifecycle of the Flexvols that contain the qtrees; that is, it creates Flexvols as needed, and it deletes Flexvols which it created and which no longer contain any qtrees. So while your request is technically feasible, I wouldn't consider it trivial. Also, we recommend using one of the other drivers, such as ontap-nas, for the backend specified during installation; that will place Trident's persistent data in a dedicated Flexvol so it may be independently snapshotted, restored, backed up, etc., as needed.

[dxlr8r]

@clintonk

Also, we recommend using one of the other drivers, such as ontap-nas, for the backend specified during installation; that will place Trident's persistent data in a dedicated Flexvol so it may be independently snapshotted, restored, backed up, etc., as needed.

For our workflow it would actually be better if I could target an existing volume as well for this. This might already be possible? In my lab now I edited the pvc and pv so I would use my premade non qtree volume (Flexvol) for this.

@kangarlou

Thanks for clearing things up. We have a set of standards, but I see that the standards might not be the best for this kinds of tasks. Having one qtree per project might lead to issues for us when it comes to billing etc. I'll have to talk with the storage department monday.

[dxlr8r]

After some more testing, I created 4 pods, each in their own project. This resulted in two flex volumes being made, and each of them having 2 qtree volumes.

For some reason I thought it was one flex volume with qtree per project.

Have you insight on which volume a pod ends up on? Is it random? On how often will it create a new volume?

[clintonk]

You must have multiple aggregates assigned to the SVM you're using for PVs and Trident. Assuming the requested PVC attributes don't require a different FlexVol, the qtree driver will reuse FlexVols for up to 200 qtrees per FlexVol. However, the core of Trident chooses from the available pools (i.e. aggregates) at random before invoking the driver, so what you describe sounds about right. If you're planning to create a large number of qtrees, and if FlexVols aren't in short supply, it's a good thing to distribute the load among multiple aggregates. If you really want to limit provisioning to a single aggregate, you can delegate just one to the SVM, or you can wait for our next release (due this month) which will let you select a single aggregate in the backend config file (identically to how it works with nDVP).

[dxlr8r]

Thanks for help, your answers helped a lot and we will continue to try trident outside of lab, and most likely take it into production. 👍