WFA: How to verify if a volume name already exists before attempting to create it?

[reide]

In my demos of WFA, I routinely run into the scenario where the supplied volume name (user input) already exists on the storage controller.  The workflow engine by default doesn't appear to make any effort to validate that the supplied volume name already exists. It dutifully executes the worklow, issues the create volume command, and then errors-out due to a name conflict.   Can WFA somehow check for the existance of a volume name supplied by the user input so it can gracefully handle it rather than erroring-out 10 commands into the workflow?

It would be EXTREMELY nice if we could design the workflow user-input screen to dynamically compare what the user is typing-in for a volume name against the WFA cache. If it finds the volume name already exists on a given controller, tell the user immediately and don't allow them to actually submit the workflow (because we know it will fail).  I can't imagine how difficult this would be to implement, but it would be extremely useful for customers.

[bdave]

Hi Reid,

I believe what you're asking for is handled via the "Enable element existence validation" checkbox under the workflow preferences.

You can also check the "Consider Reserved Elements" checkbox so that WFA will add elements/objects to its cache database at the beginning of execution so that other workflow executions will consider the new elements(objects) as if they already existed.  That way, you don't have to wait for a) DFM/ UM (/vCenter / custom datasource...) to poll and discover the new objects and b) WFA to poll the datasource and add it to the WFA cache.

Just think it through before using these across the board.  In WFA 2.0, we can't specify if a command is adding an object instance (element), manipulating it, or deleting it.  Look for that in a future release, though.  (3.0?)

Cheers,

Dave

[reide]

Dave,

Thanks. This is good info. I wasn't aware that is what these two checkboxes do, so I learned something new today.

Regarding the "enable element existence validation", what type of elements does it check for?  Just volume names or any type of element contained in the workflow (share names, LUN names, qtree names, etc...)?  For example, if I've already got a CIFS share called 'share55' and my workflow is planning on creating a CIFS share with the exact same name, will this catch that (assuming the WFA cache knows about it)?

Unfortunately, the secnario I described usually happens-mid demo with a customer on the line, so I can't always stop to investigate and figure out what happened.

Thanks.

Reid

[bdave]

It should apply to all object instances (references / elements / thing-a-ma-jigs) throughout the entire workflow execution (workflow instance).  That's why it might be tricky for some workflows in WFA 2.0, especially when one command creates something and a follow-up command sets or modifies attributes on what was just created.  For example, if your workflow creates a CIFS share in one command, then sets permissions on that same CIFS share object instance (reference, whatever) in another command, WFA 2.0 doesn't understand that in the first command the CIFS share object instance (element, whatever) shouldn't exist but in the second command it actually should exist.  That is coming in a later version of WFA, but I'm pretty sure it's not 2.0.1.  With both "Consider Reserved Elements" checked and "Enable element existence validation" checked, the example mentioned would error out every time, AFAIK.  But, with just "Enable element existence validation", I believe it should work because it will not check the reservation cache in the second command.

Perhaps Yaron and others can check behind me on this and clarify if I'm stating something wrong, but I believe "Enable element existence validation" in WFA 2.0 is supposed to work like this:

If the reference to an object (instance, element, whatever) was found by a filter or finder, WFA assumes the object was supposed to exist first, but if the reference to the object is not found but instead specified or created as a new object reference, WFA assumes the referenced object should not exist.  Make sense?

From the documentation:

Consider Reserved Elements

Enables you to set the workflow to take advantage of the reservation feature, when selected resources are available for the workflow until the reserva...

Note: Do not select this check box, if you require the filters to search only content of the persistent cache without considering reservations made by other...

Enable element existence validation

Enables you to validate the existence of elements and avoid failure of certain actions during the execution of workflows. For example, you can avoid c...

Thanks,

Dave

[yaronh · Accepted solution]

Reid,

What you wrote is not entirely accurate:

In planning, we will compare the name to the cache AND the reservation cache for validation of existence.

So it should fail in planning rather than execution.

Admittedly, there's an issue with showing reserved names in user input drop downs but that would be handled in a coming release.

What you are after is a mechanism that would make validation of a volume name based on inputs, prior to other mechanisms that are at play.

Do you know at which aggregate to check? which controller? if there's a vfiler in context or not?

Some of these are applicable from the flow design and are not necessarily known at time of input registration.

How do you propose to handle that knowledge gap?

Cheers,

Yaron

[bdave]

Difference in Yaron's reply and mine:

"Enable element existence validation" does not help prior to planning.  i.e. WFA 2.0 cannot determine if the text string entered later is used for an object that already exists or not before at least clicking the "Preview" button.  But, it does help at the planning phase and not "10 commands deep".  Right, Yaron?

Thanks,

Dave

[reide]

Yaron,

Now that I understand that the planning phase should be catching these duplicate names if they exist in the cache, I'll start digging in to figure out why I got the error.

I completely understand that it would be highly complex for the user-input screen to validate element names before the workflow even know what controllers or aggregates it will use to fulfill the workflow.  It was just a thought that would be extremely nice to have if not realistic to have.

Thanks!

Reid