Cache update in WFA not completed for vfiler table?

[dcornely1]

Hello,

I'm encountering an issue with WFA v2.0 that I think is related to this thread:

https://communities.netapp.com/thread/16622

The issue I'm having is that I'm getting an error message when I try to delete a volume that I had just created AND added to a vfiler before the OnCommand & WFA database/cache refresh cycles have run.  In WFA v1.0 the tool did not know about changes it made so it had to wait for an update from OnCommand but it does appear now in version 1.1 and in 2.0 that WFA in fact does update it's cache.  However, I'm finding that this self-update process is not complete - specifically for vfiler membership.  In my case I've tested:

1) Creating a volume, leaving it in vfiler0 and then an immediate delete before the cache update has occurred.  The workflow completes successfully.

2) Creating a volume, assigning it to a vfiler and then an immediate deletion before the cache update has occurred.  With the delete command I used a finder that only locates the volume within a given array so I don't pass it the vfiler.  The result is interesing - the workflow actually does delete the volume yet it returns this error message: vfiler vfiler0 does not have storage on volume DavidTest02

This of course creates a funky situation where the volume was deleted but anything or anyone interacting with WFA wouldn't know that.

3) Creating a volume, assigning it to a vfiler and then an immediate deletion before the cache update has occurred.  With the delete command on this test I used a finder that locates the volume with a given array and vfiler.  This command fails outright until the WFA cache update has run, telling me the WFA self-imposed cache updates don't extend to the vfiler table.

Can someone confirm that the vfiler table is not part of the self-imposed WFA cache updates and when that might be added to the tool?  Thank you.

-Dave

[chaitu]

Hi Dave,

I am assuming that you used "Add volume to vFiler" certified command for adding volume to the vfiler.

This command in WFA 2.0 supports self-imposed WFA cache updates for volume table and vfiler table. So, using this command updates the volume table with the association of volume to the vfiler. In general, the self-imposed WFA cache updates are specific to each command, and works only with certified commands. Moreover, updates done by each command inside a workflow are not visible to other commands of that workflow (in WFA 2.0). Those updates are visible only in next workflows.

1. In your test scenario 2, the error message "vfiler vfiler0 does not have storage on volume DavidTest02" is misleading as you said, and I checked that this is a bug with the "Remove Volume" certified command code. We will fix this.

2. For the test scenarios 2 and 3, have you done all of these operations (create, adding to vfiler and deletion) in the single workflow? If yes, cache updates by previous commands in the workflow are not seen by the other commands of that workflow. So the finder used in "remove volume" command details will not find the volume created by "Create volume" command. You could instead use the same volume object that is defined in "Create Volume" command details for "Remove volume" command, instead of finding it.

If you have done removal of the volume in a separate workflow, then ideally it should work. Finder should locate this volume within this workflow even though WFA cache is not refreshed, as self-imposed updates of the previous workflow should be visible in this workflow. I tried this in WFA 2.0, and works fine.

-Chaitanya

[dcornely1]

Thanks for your reply.  I am executing the commands all from different workflows (Create volume, add to vfiler, delete volume all are different workflows).  All are certified commands as well.

For the bug you mention it sounds like this is the issue we need addressed.  Is there an ETA on when that fix might be out?  Thanks!

[chaitu · Accepted solution]

Hi Dave,

If only certified commands are used, and all these commands are executed through different workflows, then you should not see the problem you mentioned. Could you please give the DARs of these workflows, just want to have a look at how they are designed once.

And also, under the "Execution" menu, we have "Reservations" tab. Here, you could see the reservations (self-imposed cache update) created by each workflow execution (either executed or scheduled). So, you could verify if there is a reservation created for "add volume to vfiler" task with the correct arguments.

About the bug, yes we will be addressing it in the early next release.

-Chaitanya

[dcornely1]

I spoke to soon - looks like I'm using a non-certified command for the vfiler add workflow.  Of the 3 workflows (Create, VfilerAdd, Delete) I changed the vfiler add command because it wasn't taking the controller name instead of IP so by modifying the parameter mapping for that input I was able to resolve that.  This was however and issue I had with WFA v1.0 so if v2.0 fixed that in the certified command then I should be able to revert back to the certified command.  I'll test today and let you know -- thanks for your help!

[dcornely1]

I recreated the vFilerAdd command using the following commands:

-Add Volume to vfiler (certified command)

-No-Op Storage (certified command - this is so I can define the qtree)

-Create Export - Global Forbidden (non-certified command)

Changing the first command from non-certified to certified fixed the issue.  I'm still unable to utilize the certified command for creating exports but that doesn't impact my use case.  I don't use the certified export command because it's written to grant export permission to everyone if there are no ro/rw hosts specified.  We feel this is a security hole and so I modified the code to put a dummy entry in place if no ro/rw hosts are specified so that no one has access.