Repository navigation
Implement Rename() for ontap-nas-economy (qtree) and ontap-san-economy drivers #1160
Description
The Rename() method is not implemented for the ontap-nas-economy (qtree) and ontap-san-economy storage drivers. Both currently return a hard error (I am planning to raise a PR for this fix):
storage_drivers/ontap/ontap_nas_qtree.go:812→errors.New("rename is not implemented")storage_drivers/ontap/ontap_san_economy.go:1185→errors.New("rename is not implemented")
This creates a feature parity gap with the non-economy variants (ontap-nas and ontap-san), which implement Rename correctly.
Impact
Volume rename is used internally during volume import operations and certain recovery workflows. Users of economy drivers are blocked from these flows entirely, receiving an opaque "rename is not implemented" error.
Root Cause
The ONTAP API abstraction layer already provides all the necessary primitives:
OntapAPIREST.QtreeRename(ctx, path, newPath)— implemented inapi/abstraction_rest.go:1452OntapAPIZAPI.QtreeRename(ctx, path, newPath)— implemented inapi/abstraction_zapi.go:1999OntapAPIREST.LunRename(ctx, lunPath, newLunPath)— implemented inapi/abstraction_rest.go:2689OntapAPIZAPI.LunRename(ctx, lunPath, newLunPath)— implemented inapi/abstraction_zapi.go:801
Both REST and ZAPI paths have API-layer tests in abstraction_rest_test.go and abstraction_zapi_test.go. The driver-level Rename() methods simply never call them.
Proposed Fix
For NASQtreeStorageDriver.Rename():
The same lookup pattern used by Destroy() applies, use d.API.QtreeExists() to locate the parent FlexVol, construct the full qtree paths (/vol/<flexvol>/<name>), then call d.API.QtreeRename().
For SANEconomyStorageDriver.Rename(): Same pattern as Destroy(), use d.LUNExists() to find the bucket FlexVol, build paths via GetLUNPathEconomy(bucketVol, name), then call d.API.LunRename().
Reference implementation for both can be modeled after:
NASStorageDriver.Rename()inontap_nas.go:888(single-line VolumeRename call)SANStorageDriver.Rename()inontap_san.go:902(with error wrapping)
Scope
- Implement
Rename()inontap_nas_qtree.go - Implement
Rename()inontap_san_economy.go - Add unit tests for both (following patterns in existing
*_test.gofiles for these drivers)
Please let me know if there are any constraints around qtree/LUN rename I should be aware of before proceeding.
Activity
torirevilla commentedon Jul 1, 2026
Hi @anshulj07, thank you for your interest in improving Trident. There are some things to know about the
Rename()function from our driver layer. This driver function is not called directly by the frontend customer, it is only used for clean up when a volume import fails. For our economy drivers we do this clean up in the import function itself since there are multiple objects being renamed, the qtree/LUN and the FlexVol. One consideration is that we may not know if it is safe to always rename both the qtree/LUN and FlexVol at the time of failure, we may need additional information to correctly find and build the current path after a partial import (if the qtree/LUN was renamed but the FlexVol was not). This will likely take more thought and careful examination rather than a couple line fix to call our abstraction layer to simply rename the qtree/LUN. We are happy to answer any questions you might have and look forward to your proposed fix if you are still willing to dive in on this.Implement Rename() for ontap-nas-economy and ontap-san-economy drivers
Implement Rename() for ontap-nas-economy and ontap-san-economy drivers
anshulj07 commentedon Sep 15, 2026
Hi @torirevilla, thanks for the detailed context that clarified exactly the case I hadn't accounted for.
I dug into the import cleanup path:
ImportOriginalName(used asnewNamewhenRenameVolumecalls into the driver during import-failure cleanup) is stored as a compound"flexvol/qtree"(or"flexvol/LUN") path, sinceImport()may rename both the qtree/LUN and its bucket FlexVol. A naiveRename()that only renamed the qtree/LUN would leave the FlexVol stuck under its new Trident-prefixed name a partial revert.I opened #1191 with an implementation that handles this:
Rename()reverts the qtree/LUN name, and additionally reverts the FlexVol name only if that FlexVol still holds exactly one qtree/LUN (checked viaQtreeCount/LUN listing) since bucket FlexVols are shared, renaming one back under other qtrees/LUNs would orphan them (theirInternalIDpins them to the current FlexVol name). If the FlexVol rename fails after the qtree/LUN rename succeeds, it rolls the qtree/LUN rename back rather than leaving a half-reverted state.If a FlexVol does hold other objects at cleanup time,
Rename()currently leaves the FlexVol name as-is (only the qtree/LUN is reverted) rather than guessing let me know if you'd rather it surface an error in that case, or if there's more context I'm missing about how that scenario should be handled.Happy to adjust based on your feedback.
Utkarshjh commentedon Sep 23, 2026
Hi @anshulj07 , Thanks for raising this - we've acknowledged the issue internally and it's on our radar. We'll keep this thread updated in case of any update. Appreciate your patience!