I'm running the latest version of WFA v18.104.22.168.32 in my environment and I've come across an issue I thought wouldn't exist because I'm using certified commands. The issue is that WFA does not appear to be aware of changes it has made before the OnCommand cache updates occur. Here is the scenario:
I'm creating a new CDOT export policy, export rule, and volume. This flow works without issue and is called ss_cdot_CreateNFSVolumeWithExport
Before WFA and/or OnCommand has had a chance to learn about the change from the step 1 workflow via scheduled cache updates I attempt to run a workflow
that creates a new rule in the policy created from step 1. This fails and will continue to fail until WFA's cache is updated from OnCommand and it learns about this new policy.
This flow is called ss_cdot_CreateExportRule
All the commands in both flows are certified so I had thought that would avoid this issue. I had originally been using a modified No-Op command in the first create flow for the reasons behind this post but even after removing that single non-certified command the problem remains. The only thing I can think of is that I created these flows in WFA v2.0 and recently upgraded to v2.1.
I'm either missing something or have encountered a bug in WFA regarding export policies and cache awareness of them, although I'm leaning towards an error I made somewhere but haven't found it yet. I'm attaching both flows in the hopes that they will reveal where I've tripped up. Hopefully it's something simple, thanks in advance.
The input is based on one of the example workflows that came with WFA, specifically "Create a Clustered Data ONTAP NFS Volume". It's a loop that will add each rule --- the number of loops will equal the number of rules requested leveraging a couple different functions.
Both workflows I attached do work successfully independent of each other. The issue is that WFA for some reason is not aware of the export policy it created for the new volume before the next OnCommand cache update occurs, something I thought I was able to work around by using certified commands.
Here is the description from the command I copied:
Export Specification Rule is an input that combines all the Export Rules for a Policy. 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 '10.10.10.10;ntlm;krb5;sys&22.214.171.124;krb5;sys;ntlm' specifies two export rules:
Export Rule 1) client-specification = 10.10.10.10
read-only rule = ntlm
read-write rule = krb5
superuser rule = sys
Export Rule 2) client-specification = 126.96.36.199
read-only rule = krb5
read-write rule = sys
superuser rule = ntlm
If you check the Reservations tab, you can see which commands get reservations created. And it appears the Create Export Policy/Create Export Rule certified commands do not add a reservations. Looks like a bug to me. I've tried creating a few other types of objects with in-built commands for cDOT and they don't have reservations too.
I got around this by defining the object if the search fails and I know its there, using other attributes from objects that did exist. However that means if its not actually there it fails at execution rather than evaluation time which isn't ideal.
Here's my initial list of cDOT commands missing reservations so you don't hit them. It would be really nice if we could create custom reservations for our commands easily in the field!
- Create Export Policy
- Create Export Rule
- Create CIFS Share
- Remove CIFS share ACL
- Add CIFS share ACL
Sorry I don't have a better answer, but I can definitely reproduce your problem (and have been working around it myself).
For now, I would suggest defining the object instead of searching for it, since you are passing in the rule name anyway, and the vserver search will work because its not a new item.
I am able to reproduce the issue.
To get around this issue, You can reduce the DFM option "sharemoninterval" to a low value like 30 seconds or 1 minute. That will acquire the data on export-policies. Also reduce the acquire interval for data sources on WFA to a low value. But then again, it is a tedious job and you may end up waiting a few minutes between the two workflows.
As michael said, export policies do not have reservations. It is not a problem with the command.
I am curious as to why you are not using the certified workflow "Create a clustered Data ONTAP NFS volume" which does the same job as the two of your workflows combined?
Thanks for the info on the timeouts - I've got the updates down low already but don't want to make the OnCommand one so low that it add unnecessary load to the cluster.
I've split the 2 flows out because I have to solve for a use case where a customer first provisions a new volume/NFS share and then immediately turns around to add more export rules, perhaps because they forgot about them initially. I don't make up these use cases nor do I establish what is a reasonable SLA for these use cases. I just have to do my best to achieve the SLA for the use cases.
Good news! I've created a custom Create Export Policy command that includes reservations missing from the certified command, you could use it to also avoid the problem in a more robust manor, attached below.
I tested by replacing the certified command in the first workflow (CreateNFSVolWithExport), and the second workflow now finds the policy before a polling cycle.
Hope that's useful!
I'm looking for a way to use reservation in my custom commands, for caching purpose.
I saw in xml file:
INSERT INTO cm_storage.export_policy
SELECT NULL as id,
PolicyName as name,
vs.id as vserver_id
FROM cm_storage.vserver vs
ON (cl.primary_address=Cluster OR cl.name=Cluster)
AND vs.cluster_id = cl.id
AND vs.name = VserverName;
Is it the clue?