VMware

One of the challenges when using the NetApp vRO Package for WFA has been making the inputs dynamically populate with the correct information from WFA. If you add a new volume, aggregate, SVM, or other entity to your NetApp, you want it to show up in your workflows to be able to take advantage of it. There are workarounds, such as using the database or creating a filter/finder to retrieve the information, but each of those was flawed, primarily because they would not be updated to use new query parameters automatically if the WFA admin updated the workflow. Fortunately, WFA 3.0 has fixed this by adding a new REST method to the workflows namespace which will return the valid values back for you.

To take advantage of this we need a helper action to retrieve the values from WFA, and another helper to provide the dependent inputs and extract the information we want from the response and put it into the correct format for a vRO input.

Not too long ago we released a new version of the vRealize Integration Package for OnCommand WFA v3.0, which had a significant number of improvements around speed, flexibility, and overall robustness.

The vRealize Integration Package is a series of vRO workflows which take advantage of Workflow Automation’s REST interface for executing workflows. Version 3 of the package has been almost completely rewritten to be faster and easier to use than previously. This was done by implementing functionality using scriptable tasks, storing the WFA REST host connection and referencing it, and improving the debug log output.

New with this version is the vRealize Orchestrator action getUserInputValues. This action relies on functionality found in WFA version 3.0+ where the REST API has the ability to return valid values for WFA inputs which are “query” fields. This action makes it easy to add dynamic, real-time population of workflow inputs based on the actual WFA data.

Update (2016-02-01) – The package is now available on the NetApp Toolchest! This is the best location to get it from as it will always be up-to-date.

In the last post we covered how to create Filters and Finders in WFA so that we could access WFA data through a RESTful interface. This creates a nice separation between the two systems and decouples the dependency on the WFA database for dynamically populating data in vRealize Orchestrator workflows.

Let’s look at how to take the result of the last post, query the data from vRO, and incorporate it into vRO workflows.

I’m going to be using the same workflow as before, “Create a Clustered Data ONTAP Volume”, so we will once again need four inputs:

Cluster Name – A string with valid values being clustered Data ONTAP systems configured in WFA

Storage Virtual Machine Name – A string with valid values being SVMs belonging to the cluster selected above.

Volume Name – A string provided by the user.

Volume Size (in GB) – A number provided by the user.

To get started, we are going to create vRO actions which execute REST operations against the WFA filters/finders to return the same data that we used direct SQL queries for previously. These actions will then be executed/used from the workflow presentation.

Using the database to get information from Workflow Automation (WFA) and create dynamic vCenter Orchestrator (vCO) workflows is one way to add dynamic data fields to those workflows. However, it just feels dirty. It’s a “backdoor” if you will, and just not very scalable or supportable. Imagine if the WFA database schema changes…you will be responsible for changing all of the SQL queries in the vCO workflows, which make break in non-obvious ways.

A much more robust method is to abstract those queries (and keep them in WFA) then use REST to retrieve the data. WFA provides two mechanisms, filters and finders, for selecting and returning data from the database internally. We can access these through the REST interface, which we can then parse from XML into a more vCO friendly format.

What is a filter?

A filter is simply a SQL select statement that has been validated to return certain fields (the natural keys at a minimum).

What is a finder?

A finder is one or more filters.

Putting them to work

Both of these constructs use SQL to query the WFA cache database (which is periodically updated from the data sources such as OnCommand Unified Manager), however a finder does not have SQL directly in it, only the filter does.

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.

The lastfewposts 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.

The lasttwo 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 coupleof posts that do an excellent job of describing the setup process on his blog.

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).

As I have transitioned from being a customer to being an employee with NetApp I have become aware of the breadth of integration between VMware and NetApp. I have realized that as a customer, I was only using a small amount of what is available. There are a lot of software bits-and-pieces, and documentation, that make life much easier for admins, and I have struggled to find a consolidated listing (maybe I haven’t looked hard enough…or asked the right people…?). This blog post is my attempt to provide a starting place for information regarding NetApp integration with VMware.

As I go through the process of learning, I hope to document as much as possible, and I invite you to follow along…hopefully we can all gain some insight into the resources available.

Firstly, always begin with TR-3749 and TR-4068. These are the primary references from NetApp regarding VMware integration…I highly recommend that if you have not already read them you do so now.