WFA reservations - How do they work?

[mshearer]

I am trying to better understand reservations and how they work in WFA.  My understanding is that when a workflow is planned but not executed yet the information is placed in the reservations table for all workflows and then when the workflow is executed only some workflows keep their reservation information in the reservations table.  First is this correct that after execution only certain workflows will keep their information in the reservations table until the changes are reflected in the WFA database?  Second, if that is correct, why and is there a way to specify or enable a workflow to retain its information in the reservation table until the change is reflected in the WFA database?

Thanks

[bdave]

Hey Matt,

Thanks for the opportunity to plug the new WFA workflow developer's guide.  It's available on the support site (support.netapp.com) --> Documentation --> OnCommand Workflow Automation --> 2.1RC1 --> All documentation --> Workflow Developer's Guide  -->  See the section on how Reservations work starting on page 26.

Or, the WFA help documentation also documents this and more.  In the printable format on the support site, you can find not only the content from the developer's guide but also more information on the various settings for reservations, like the WFA global parameters for reservation expiration, failed workflow reservation expiration, how to view and clean reservations, what the workflow settings checkboxes for "Consider reserved elements" and "Element existence validation" do, and how it relates to reservations.

To your specific questions, the way I understand it's supposed to work is that only if the "Consider reserved elements" checkbox is checked will the workflow either add reservations during planning or check the reservation tables when validating element existence.  It gets tricky when you have things like a workflow that has one command that creates an object and then a second command that modifies the new object.  Supposedly WFA 2.1 has a fix for dealing with reservations between commands within the same workflow, but I haven't seen it in action yet.  And yes, reservations are retained in the reservation table until either it's detected in a cache update or the reservation expiration time has elapsed (4 hours is the default) or if the workflow failed, the failed workflow expiration time has elapsed (2 days default). 

The reason for hanging on to the reservations for failed workflows longer is in case an architect or operator fixes the underlying issue and wants to resume a workflow.  The elements will be reserved longer.  Even if the reservations expire from the cache, you can still attempt to resume a failed workflow.  It's just that without reservations there's a chance the elements were used by another workflow in between.

In my opinion, it is the ultimate goal to one day specify for each parameter of a command that is mapped to a WFA object reference, what the command will do with it.  You will be able to specify if the object parameter will be created, modified, unchanged, or deleted by the command's successful execution.  (This could also get us one step closer to WFA workflows having a rollback capability.)  I have no clue if or when the WFA developers will implement such changes in WFA. 

Today the key is that if one workflow execution reserves an element (a.k.a. a reference to an object, or as I might say an "instance of an object"), other workflow executions cannot issue commands against that "element" until the reservation is removed or expires.  But, I _think_ that if the "consider reserved elements" is unchecked, a workflow can still operate on an element that might be in the reservation table.  Can someone verify or clarify that for me?

Thanks,

Dave

[shailaja]

Hi Dave,

>>Supposedly WFA 2.1 has a fix for dealing with reservations between commands within the same workflow, but I haven't seen it in action yet. 

[Shailaja] Thats right. In 2.1, reservations are considered between the commands of a workflow also. In previous releases, the reservations were only across workflows and not within the workflow.

For example: Lets say there is a workflow which uses the command "Create volume" twice and the resource selection ended up selecting the same aggregate for both these volumes. Now, the space consumption in the aggregate by the first volume should be considered before considering the same aggregate for the second volume.

>> Today the key is that if one workflow execution reserves an element (a.k.a. a reference to an object, or as I might say an "instance of an object"), other workflow executions cannot issue commands against that "element" until the reservation is removed or expires.  But, I _think_ that if the "consider reserved elements" is unchecked, a workflow can still operate on an element that might be in the reservation table.  Can someone verify or clarify that for me?

[Shailaja] If a workflow execution creates a volume of lets say name "datavol1", then as long as the reservation is valid, any subsequent workflows can consider this volume. The subsequent workflows could be to create a qtree or LUN on that volume. However, if an attempt is made to re-create the volume with the same name "datavol1", then it would fail till the reservation expires.

In case, the volume did not get created, you would have to go to Execution->Reservations and clean it up before proceeding to create the volume with the same name.

Thanks,

Shailaja