Active IQ Unified Manager Discussions

Workflow for setting export rules in CDOT (a la 7mode)



I'm sharing a workflow I put together with some help from a developer I work with because I think it might help others in a similar situation.  My work with WFA has been mostly around web services so this flow was designed that way, which is why all the inputs are simply strings.  I don't think it'd be too hard to modify that for WFA GUI usage if you want populated drop downs.

We were under a tight timeline for adoption of CDOT in our cloud environment and what that meant was no time to make our Storage Service stateful to accommodate the differences in the way CDOT manages NFS exports.  If you recall the way NFS exports were managed in 7mode, any changes to an export required rewriting the entire entry in the /etc/exports file so you really didn't need to know what was already there.  But CDOT operates in a more stateful manner, something we didn't have time to account for so we needed WFA to handle this for us.  The result is a workflow that will take a set of export requests and to our Storage Service it appears that it is rewriting the entire ruleset just like in 7mode.  What is actually happening is as follows:

First, the workflow will initially make a comparison between the export rules that exist in the export policy and the list that is provided by the Storage Service.  Any clients that currently exist in the export policy listing but not in the new list provided by the storage service are removed from the export policy.  Remember that this is because we want to act like 7mode where we rewrite the entire export entry each time.  This all takes place in the second command - this is where the extra PowerShell code was inserted, written by my colleague with a little help from me regarding inputs and outputs.

Second, we now enter a looping mechanism that will loop through each rule provided.  Here is how the loop works:

  • We first check if the rule exists and if it doesn't the command is disabled and we move onto the next command in the loop.  If the rule was found we've simply established it in a reference variable that the next command will leverage for the rule index.
  • The next command will run if the rule was found in the initial check.  We leverage the rule index it was found as in the first check and rewrite the rule with the new permissions.
  • The final command in the loop will create a new rule based on the input, because it runs if the first check didn't find the rule at all.

Hopefully this is useful to some of you.



Forgot to add the details about the export rule format.  This whole looping mechanism and format was taken from one of the certified commands that comes with WFA, I just don't remember which one.

Export Specification Rule is an input that combines all the Export Rules for the Volume.  Each Export Specification Rule is of the form:

<client-specification IP>;read-only rule;read-write rule;superuser rule

Individual rules are separated by an ampersand (&).

For example, the export rule spec ';ntlm;krb5;sys&;krb5;sys;ntlm' specifies two export rules:

Export Rule 1) client-specification =

read-only rule = ntlm

read-write rule = krb5

superuser rule = sys

Export Rule 2) client-specification =

read-only rule = krb5

read-write rule = sys

superuser rule = ntlm