We ran in this error message during a poc with trident ontap-nas-economy-driver and rancher.
Normal ProvisioningFailed 28s (x11 over 9m) netapp.io/trident encountered error(s) in creating the volume: [Failed to create volume prometheus-wllpw-prometheus-wllpw-alertmanager-c0a58 on storage pool xxxxxxxxx_data_aggr from backend ontapnaseco_10.21.XX.XX: volume k8s_xxxxxxx05_prometheus_wllpw_prometheus_wllpw_alertmanager_c0a58 name exceeds the limit of 64 characters]
The volume name is dynamically generated by Rancher during application deployment. The limit seems to be a limit by Trident. ONTAP does support longer volume names. Therefore this limit should be set in trident to a higher number or without any limit when using ontap-nas-drivers.
The limitation comes from ONTAP as ONTAP has a 64-character limit for qtree names: https://library.netapp.com/ecmdocs/ECMP1196986/html/GUID-C594875B-F58F-475E-B477-96EB95F768BE.html
The ontap-nas-economy driver provisions qtrees for the persistent volumes, whose names are limited by ONTAP to 64 characters. By using a shorter namespace name in Rancher, and a shorter storage prefix in your Trident driver config file, you may be able to squeak under the limit.
We're also hitting this limitation on a regular basis. The suggestion to use shorter namespaces or a shorter driver prefix will only do so much to alleviate this issue, and seems rather hackish. With the rise of kubernetes in mind, could it be technically feasible to review this limit?
I second this. It might not be technically possible to raise the limit, but the driver could detect that the name is > 64 chars and using the ontap-nas-economy driver and then use an uuid etc. instead.
Hitting the same issue, I like @dxlr8r suggestion of storing a unique identifier. There would even be room for adding storage prefix then also.
any updates? we are hitting this very same issue.
Also hitting the same issue..
On Mon, Jul 8, 2019 at 12:59 PM Johan notifications@github.com wrote:
Hitting the same issue, I like @dxlr8r https://github.com/dxlr8r
suggestion of storing a unique identifier. There would even be room for
adding storage prefix then also.—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/NetApp/trident/issues/174?email_source=notifications&email_token=AIFRMKDAAFMRS3VKBLSOCEDP6MMXLA5CNFSM4FTVDQB2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODZMXO3Y#issuecomment-509179759,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AIFRMKCB32OO3NKKMO2NJ4DP6MMXLANCNFSM4FTVDQBQ
.
All - this issue is closed! See the original answers from the Trident team above.
True, while this one is closed, it's been re-opened under #260 .
Most helpful comment
We're also hitting this limitation on a regular basis. The suggestion to use shorter namespaces or a shorter driver prefix will only do so much to alleviate this issue, and seems rather hackish. With the rise of kubernetes in mind, could it be technically feasible to review this limit?