2012-05-03 05:45 AM
I tested WFA reservation and it didn’t work as I expected it to work. Not sure I am getting it right…
I schedule a workflow to create a volume “wfa_tvol” on filer “stx601labna16” which should in reservation table. Then I manually executed the same workflow with same volume name and array. It executed fine. After this scheduled workflow failed because same volume name already exist on filer.
I was expecting manually executed workflow to fail as we have scheduled a workflow with same name volume and it was present in reservation.
Solved! SEE THE SOLUTION
2012-05-03 07:18 AM
If I understand your scenario correctly... Yes... that would cause the scheduled WFA workflow to fail. You are trying to perform the SAME action against your storage controller "stx601labna16" from TWO different places. One of those being from WFA, and one being on the storage system itself (cli, fileview, system manager, script, etc).
You are correct in that you're expectations are not right. WFA will keep track of what WFA is going to do. If you had tried to execute another WFA workflow, then your next execution should have failed since we know from the WFA Reservations that the volume is slated to be created. If you (or someone else) performs an action on your storage systems outside of WFA ... WFA will have NO understanding of those actions until it acquires again from the OnCommand that monitors that storage system.
The other aspect here is the Scheduled WFA workflow. At the time it is scheduled... those are the actions it is going to take. The scheduled WFA workflow knows what storage objects it is going to create, and which resources to consume. There is no looking back. The Reservations are purely used when Executing a workflow... and to help with the Planning of the workflows.
Another thing to consider is more your storage automation methodology. If you are going to automate and standardize your storage management with WFA, then try to use only WFA. If you think you are going to be performing MANY different tasks outside of WFA, then you might need to be a bit more aggressive with your WFA DataSource acquisition interval (i.e. every 5 or 10 minutes). Ideally you'd automate things in your environment from one place only.
Hope this helps,
2012-05-03 07:52 AM
Thanks for reply!
I am actually doing all provisioning through WFA not through Filer. I first scheduled a workflow (to run next day) to provision a volume then I straight away successfully ran a same workflow to provision with same volume name on same array. I was expecting this workflow run to fail as I already have a scheduled workflow with same name volume on a same filer.
2012-05-03 08:45 AM
Okay. Thanks for the clarification. One last clarification question. In the workflow itself is the 'Consider Reserved Elements' checkbox "checked"... here's a screenshot:
If it is NOT checked, then this is probably the issue. If it IS checked, then we'll probably have to take a deeper look into things.
2012-05-03 09:27 AM
I think you are doing everything right on this front. Your expectations that the second workflow will fail are valid and they will be implemented in the second phase for this capability which is planned for WFA 2.0.
Let me provide a little more detail:
1. The reservations in WFA 1.1 reserve resources for all scheduled and executed workflows. These reservations are visible for filters and finders. This means you can run a finder which will check if the volume name exists and if it does you can create an error in the find-chart.
2. There is currently no automatic mechanism in the WFA infrastructure which checks for the existence of an object (volume in your case) prior to the its provisioning. This mechanism is planned for WFA 2.0. Once this mechanism is in place, the expectations you mentioned in your original post will be met and the second workflow in the scenario you described will fail.
3. As mentioned in the first point, you can have a workaround for now in which you check whether the volume exists with a finder in the workflow.
I hope this helps and clarifies the issue.