July 2014 - The Practical Administrator

Installing Modules to WFA Perl

2018-07-202014-07-21 by Andrew Sullivan

NetApp’s Workflow Automation (WFA) supports two languages out-of-the-box: Powershell and Perl. Adding modules to the perl installation is done in a non-obvious way because the install does not include ActiveState’s PPM package manager.

However, the PPM command line utility is included. Here is how to use it to manage the packages on your system.

First, you will need to open a command prompt with elevated privileges. Click the start button, find “cmd”, right click and select “Run as Administrator”.

# browse to the correct location
cd %programfiles%\NetApp\WFA\Perl64\bin

# use the ppm command line utility to view the repos
ppm repo list

# if you don't see the ActiveState repo, add it using the following command:
ppm repo add activestate

# once that's done, install the modules using the ppm install command
ppm install DBD::mysql

# if you want to know all of the modules on your system, use this command:
ppm list

# you may also need to execute the following command to make sure the 
# module database is up-to-date
ppm area sync

# browse to the correct location

cd %programfiles%\NetApp\WFA\Perl64\bin

# use the ppm command line utility to view the repos

ppm repo list

# if you don't see the ActiveState repo, add it using the following command:

ppm repo add activestate

# once that's done, install the modules using the ppm install command

ppm install DBD::mysql

# if you want to know all of the modules on your system, use this command:

ppm list

# you may also need to execute the following command to make sure the

# module database is up-to-date

ppm area sync

Using the vCO-to-WFA database connection

2018-07-202014-07-14 by Andrew Sullivan

Previously we connected vCenter Orchestrator (vCO) to the NetApp Workflow Automation (WFA) database in order to perform queries against it. By itself this isn’t terribly useful when we are wanting to provide dynamically populated information to vCO workflows that are executing WFA workflows using REST.

The crux of the problem we are trying to address is that when executing a WFA workflow via REST we are not able to pre-determine valid values for inputs like the cluster or storage virtual machine names. The administrator(s) can provide static values, but this is only helpful with a subset of inputs (how frequently do you add a new cluster?). For volumes, which have the potential to be added and removed frequently this would become a burdensome task quickly.

One answer (there are others, which I will post about in the future) is to use the database. When a WFA workflow is executed natively (i.e. from WFA) it uses query based fields to determine those inputs. The data is populated by crafting SQL commands to pull the data form WFA’s cache database.

Connecting vCenter Orchestrator to the WFA database

2018-07-202014-07-11 by Andrew Sullivan

The last few posts have been describing how to use REST to execute NetApp Workflow Automation (WFA) workflows remotely. The most recent post showed how to use the NetApp Workflow Automation Package for vCenter Orchestrator to execute those workflows by simply calling one vCenter Orchestrator (vCO) workflow.

However, if you followed along in that post you noticed that the data which is dynamically populated in drop downs and lists when executed from WFA is static when executed from vCO. WFA uses it’s database, which is periodically updated from OCUM, to provide real-time information when executing workflows. This includes selecting, and filtering, things like available clusters, storage virtual machines, and other important data when executing WFA workflows from the WFA GUI.

How do we get that information into vCO so that we can provide dynamic, valid, choices to the user who is executing the vCO workflow? Well, it turns out there are a couple of ways, but for this post, and the next one, we are going to focus on connecting vCO to the WFA database. In the future we will also include another way, using REST to query WFA finders.

This post will focus on connecting vCO to the WFA database and executing basic queries. The follow-on post will show how to integrate those queries into vCO workflows.

Using the NetApp OnCommand WFA package for vCO

2018-07-202014-07-10 by Andrew Sullivan

The last two posts have shown some interesting possibilities regarding integration between VMware’s vCenter Orchestrator (vCO) and NetApp Workflow Automation (WFA), however both methods were rather cumbersome. Having to write 100+ lines of javascript in a vCO scriptable task is not exactly convenient!

Fortunately, NetApp has published a vCO package which abstracts all of that code into a handful of workflows and actions easily consumed by vCO workflows. To execute a WFA workflow from vCO you only need to know the name of the WFA workflow and the inputs needed.

The package is available from the NetApp Communities here. Once you have downloaded the package, installation is easy, simply import it into your vCO instance using the GUI. You will need to do a bit of configuration (adding the WFA host name and credentials), but that’s it. Jack has a couple of posts that do an excellent job of describing the setup process on his blog.

Executing WFA workflows from vCenter Orchestrator using REST

2018-07-202014-07-09 by Andrew Sullivan

In the previous post I showed how to execute a NetApp OnCommand Workflow Automation (WFA) workflow using the REST cmdlets available in Powershell version 4. However, any language or platform can be used for execution via REST, including VMware’s vCenter Orchestrator (vCO).

For the most simple execution we can simply add the WFA host as a REST host to vCO. When the REST plug-in is added to your vCO instance, it adds some helper workflows for managing the connected hosts. Let’s start by executing the “Add a REST host” vCO workflow (located at Library->HTTP-REST->Configuration).

Executing WFA workflows using REST

2018-07-202014-07-08 by Andrew Sullivan

NetApp’s Workflow Automation (WFA) tool is a valuable asset for providing easily consumed scriptable tasks to perform nearly any function that storage administrators require. For administrators who want to get out of the business of doing mundane tasks, like provisioning generic volumes, adjusting volume sizes, etc., WFA gives you the ability to surface those operations to storage consumers and have them do the work for themselves.

WFA can also play a part in a larger scheme of workflows that can be orchestrated by other software, for example VMware’s vCAC, Puppet, Chef, Microsoft Orchestrator, etc. This leaves the power (and details) of how to automate the task with the storage team, but enables the IT organization to leverage storage resources in a programmatic manner. This is done using the REST interface.