3 weeks ago
I'm looking for a way in WFA to add Export-Rules to an Existing Export-Policy which is assigned to an Qtree.
As we try to keep the questions for our end-users low I try to resolve the Export-Policy based on the Qtree-path.
It looks like WFA can only read the Export-Policy connected to the Volume with "qtree.volume.export_policy.name" dictionary-item.
Is there a way to add this to the dictionary and get this updated from OCUM?
I'm currently running WFA 4.1 with OCUM 7.2.
I found some posts about an updated "Create Qtree" command but it only pushes the configuration but it can't fetch it.
2 weeks ago
I just checked the WFA database, and unfortunately the export policy (id) is not a column within the qtree table.
You can create custom commands (Powershell Code) to figure it out and add/remove servers from an export policy.
Another alternative, is to have a 1-to-1 relationship of qtrees to export policies. You can then call the export policy the same name as the junction path to the qtree. (Export policies can contain slashes) . Then you can do a lookup on the export-policy based on the qtree path.
2 weeks ago
Thank you for your answer!
I was afraid it wouldn't be possible out-of-the-box.
We would like to have a worklow which is usable for our present install-base so changing the Export-Policy isn't preferable.
Making a new Command to get the Export-policy sounds the only way at the moment.
I'm pretty new to WFA. Are there ways to get this information included in the WFA database?
I don't know how active the NetApp development is on this community?
2 weeks ago
Even if you are going into a "brown-field" deployment to do automation, you can get all the qtrees over to new export-policies or renamed export policies.
I did this back in Ontap 8.2 days, so please test if you want to roll with this idea.
If you already have a one-to-one mapping of export-policy to qtree export, you can do an "export-policy rename" command on the Ontap Cluster without any impact.
If you don't already have a one-to-one mapping, (IE 1 policy to many exports), you can copy the export-policy through the "export-policy copy" command. This will create duplicate export-policies, that you can then modify the qtree export (qtree modify) to be that copied version with the new name.
This idea has some leg work obviously, but gets to the end goal. This also allows you to use the out of the box approach mentioned previously.
To be honest, I'm not sure of the official channel of making a feature enhancement, but this channel is a spot I throw my suggestions now and again. Your suggestion of getting the qtree's export-policy assigned in the DB is a good suggestion, and probably wouldn't be that hard. However, WFA is dependent on the data in OCUM. Thus, if OCUM isn't collecting it, they would need to do an enhancement there as well.