VServer nfs-exportfs-* mappings in C-mode?

[kevingraham]

While I'm really glad to see the nfs-exportsfs-* API's available for C-mode VServers, the documentation doesn't cover how these map onto C-mode's implementation of export policies. The API's are all path-oriented, whereas C-mode manages policies which are later attached to paths, but I couldn't find any discussion on how this layer of indirection is managed.

For example, if multiple exports are using the same policy and the "rule" is modified by the API, does that clone-and-modify the policy and apply it to the path referenced in the API call? Similarly, given the relatively limited number of policies

[rle]

Hi Kevin -

As you know, cluster-mode exports do not follow the 7-Mode model of file-based access definition, in which the file system path is described first and then the clients who want to access the file system path.  Cluster-mode has export polices that are applied to volumes, rather than to particular paths as in 7-Mode.  Export paths in cluster-mode are call junctions.  This allows volumes to move around, and keep the same export path.

From some API experimentation, it looks like that nfs-exportfs-list-rules-2 generates <security-rules> from the export policy assigned to the volume.  The <pathname> used is the junction name, not the volume name.  For each volume assigned to the export policy, nfs-exportfs-list-rules-2 list the same <security-rules> for a different <pathname>.

To list all the export rules in cluster-mode, use export-rule-get-iter.  This API describes all the export rules per export-policy.

I also tried using nfs-exportfs-append-rules.  Instead of appending a new rule to the export policy, it changed the rule.  I don't know if this is the intention or a bug.

My recommendation is use cluster-mode as it is intended to be used with export policies attached to volumes.  If you desire to used the nfs-exportfs-* APIs, I recommend only using nfs-exportfs-list-rules-2.

Regards,

   - Rick -

[kevingraham]

Rick -- sorry for the delay, I missed your update...

I also tried using nfs-exportfs-append-rules.  Instead of appending a new rule to the export policy, it changed the rule.  I don't know if this is the intention or a bug.

At least then its a documentation bug? (Though modifying a rule that is being applied outside of the context of the provided path would seem to be a major flaw).

My recommendation is use cluster-mode as it is intended to be used with export policies attached to volumes.  If you desire to used the nfs-exportfs-* APIs, I recommend only using nfs-exportfs-list-rules-2.

Unless I'm missing a section in the SDK, there is no way to manage export polices/rules. The only (documented) API's are export-policy-get-iter and export-rule-get-iter so the only way to "use cluster-mode as it is intended" is to "not automate".

As-is, I don't see way to handle the simple use case of "provision a volume and make it accessible via NFS".

[rle · Accepted solution]

Hi Kevin -

Export policy creation is done with Vserver API export-policy-create in Clustered ONTAP 8.1.

Regards,

   - Rick -

[kevingraham]

Rick Ehrhart wrote:
Export policy creation is done with Vserver API export-policy-create in Clustered ONTAP 8.1.

Got it! I didn't realize that the VServer API's weren't just the 7mode-like API's (and never noticed that whole new category).

Perhaps more for the SDK team, but given that they're all lumped together, are there plans to flag ZAPI's as "legacy compatibility" and/or "deprecated"?