Forcing OCUM to update from WFA

When I run a workflow from our WFA 4.1 server the WFA server does not seem to be immediately aware that the workflow has been run. For example, we have workflows to incrementally name volumes: Vol_Prod1, Vol_Prod2, Vol_Prod3, etc. If I run the workflow back to back, it creates the first volume successfully, but when I try to run it again, it tries to create the same volume name again. If I manually do a re-discover in OCUM and then do an "Acquire Now" from WFA, it becomes aware of the new volume and the workflow then runs correctly.

I was under the impression that WFA had its own local database that should be updated when the workflow runs so that it should know about the changes it just made. Isn't that what the reservations are for?

If this is not the case, is there a way to get WFA to force OCUM to do a rediscover and then an "Acquire Now" before kicking off a workflow to make sure that the WFA database has all the most recent information in its database?

Re: Forcing OCUM to update from WFA

Just out of curiousity, what is the downside to running a rediscover before each workflow? Obviously that would add to the time it takes for the workflow to complete, but I can't see any other downside. And, if the customer isn't too worried about the runtime, it may make sense to prevent this issue.

I did just confirm that if I run a workflow twice in a row, it tries to create the same volume name twice (despite the fact that it is supposed to increment the name) unless I force the updates between runs. The workflow(s) I'm using originated from the certified workflows, but have been heavily modified from them. Some of them were modified before I started here by someone who is no longer with the company.

In the Details tab of the workflow, I do have the box checked for "Consider Reserved Elements". After I run the workflow, if I look at "Reservations", it lists the job as successful, but it says "NO" under "Cache Updated." If I wait a few minutes, that eventually changes to "YES".

On the one I just ran, I do see a few error messages similar to the following in the workflow logs:2017-10-18 10:54:35,390 INFO [com.netapp.wfa.engine.reservations.ReservationsRunnerImpl] (default task-30) Failed to run reservation script for reservation with id '11': Column count doesn't match value count at row 1

This is the code under the "Reservation Script" of the Vol Creation Command. It looks like it's the same as the certified command, but maybe when we modified the command it invalidated something in this code? This reservation script seems like a lot more code than is necessary for just a volume creation:

Re: Forcing OCUM to update from WFA

"what is the downside to running a rediscover before each workflow?" . I do not recommend this approach, it is not scalable or efficent. Doing so would require OCUM to invoke ZAPI's to perform a storage rediscovery to the cluster and then have WFA update the OCUM datasource each and every time the workflow is executed. Yes it will work however this may have unintended consequences in terms of performance and load. I guess it depends on your environment and the intended frequency in which the workflow will be invoked. Reservations are designed to avoid having to immediately rediscover the storage and WFA datasource. I'd be more inclined to work on resolving the error with SQL reservation code.

/Matt

If this post resolved your issue, help others by selecting ACCEPT AS SOLUTION or adding a KUDO.

I first made these redicover and DS acquire commands when WFA didn't expose the reservation tab for the commands. So this approach works even for old WFA versions. The biggest advantage is its great simplicity and absolute reliability. This is mostly for beginner to intermidiate level WFA users.

The biggest problem of using Reservation appraoch is the exact one you are facing, i.e. complexity in building the right query which can work well. This was the very reason Reseravtion wasn't exposed for editing in the old WFA. You need to take care of lot of things and all on your own and that can be a problem to many WFA users. Ese you'll be spinned into a rabbit hole which can be difficult to get out of. Reservation is recommended for Advanced WFA users.

There are other issues as well. The advantage is this doesn't make any API calls to OCUM or any DS aquisition. So that time is saved. Plus other very useful WFA features like reservation within workflows, element existance validation, incremental naming etc are all possible with this approach and NOT with the previous.

sinhaa

If this post resolved your issue, help others by selecting ACCEPT AS SOLUTION or adding a KUDO.

Re: Forcing OCUM to update from WFA

After this original discussion, I was able to create a pretty simple workflow that refreshes the cluster data on OCUM, and then acquires the data from OCUM. It's been working very well, so thanks again to everyone for the help putting that in place.

The only problem I have now is that I have to manually define the data source and OCUM server names as strings in the User Inputs. This isn't a huge deal, but if I have multiple environments (i.e. R&D vs. Production), I have to remember to change that input when I copy the workflow between environments. Is there a way to automatically pull those names? It looks like that information is available in the "wfa.data_source" table, but when I try to run a SQL Query against it, I'm getting the error: