I just put the finishing touches on my workflow packages for the Pure Storage FlashArray for VMware vRealize Orchestrator! Download it here:

https://github.com/codyhosterman/orchestrator

Three important notes on this package:

1. This is not officially supported by Pure Storage yet, I made this, not our engineering. Treat this like a VMware Fling. We support the underlying REST calls of course, but cannot guarantee support directly on the package (I will supply best effort). We will analyze demand for this though hopefully release a fully supported one in the future. If you like it, or want more, or more frequent updates, please let us know!
2. This is open source, when you import it, you can edit it all you want, this is not locked down. Though I advise copying a given workflow to a new one so you can edit it and keeping the originals unchanged. This makes troubleshooting easier.
3. Contribute! Please post your own additions and changes on Github or our community. Let’s see what everyone can do.

The workflow has been tested with vRealize Orchestrator 6.0.3 and 7.0. It should work with older versions as long as they have the REST plugin. From the FlashArray perspective, it requires any Purity version that runs the REST API 1.4 or later. Nothing else really matters, it supports both the 400 series and FlashArray//m.

One thing to note about vRO is that you likely already own this product. Unlike the other products in the vRealize suite, its license is included with vCenter. So if you are looking into orchestrating/automating your environment, especially a VMware-centric one, you probably do not have to buy anything, so start looking at vRO.

At a high level, what is vRO? vRO is a orchestration tool that operates on the concept of combining various workflows to perform a specific task. Essentially it replaces the idea of writing scripts that you might do today with a GUI-managed set of plugins, workflows and APIs. So, you do not need to worry about what type of API/protocol does this switch support and this storage array and this application. vRO offers plugins like SSH, PowerShell, REST, SOAP and others that can talk to any number of endpoints. Furthermore, many vendors (or the community at large) provide their own plugins to help make it even easier to talk to and manager their products from vRO.

A vendor can supply a workflow package or a plugin. A plugin is really a new set of capabilities specific to a type of target or an access method that may not exist innately inside of vRO. A workflow package is a collection of workflows that use a pre-existing plugin or plugins to do some of the initial work for you on connection to certain objects.

So in the end, everything comes down to the workflow. So you might have a workflow that is something simple: format a VMFS volume. It takes in a device ID and a VMFS name and returns success or failure. Just running that isn’t much of an advantage from an automation or orchestration standpoint though. So, instead, you have that workflow provided by VMware and you have one provided by me, for instance, to create a new volume on the FlashArray. My workflow takes in a name and a capacity and returns the new volume serial number. You can then create a larger workflow that encompasses both. The first creates the new FlashArray volume and then passes the serial number to the next workflow which formats it as VMFS.

Inside a workflow can have a whole variety of objects to manipulate and manage the data. It really is no different in concept to scripting. There are foreach objects, decision objects, switches and many more.

The FlashArray Workflow Package

The workflow package is based off of the HTTP-REST plugin already inside vRO, since nothing besides REST calls are required to connect to a FlashArray. The workflow package is intended as a set of building blocks that you can assemble to build whatever you want.

The metaphor I like to use is that we give you the Legos, you make the rocket ship, the pirate ship or something that isn’t a ship (I built a lot of Lego ships when I young).

The package covers about 70% of our REST API, anything revolving around host management, volume or snapshots, replication and array information is there. What isn’t currently included are things like certificate management, directory configuration etc. Mainly things most wouldn’t necessarily need to be orchestrated aren’t built in, but they certainly could be with no too much effort.

The workflows are in six segments:

1. Authentication–this is for managing API tokens and creating sessions to a FlashArray
2. Host Management–creation of hosts or host groups, provisioning storage to them etc.
3. Array management–general FlashArray management at the array level
4. Protection Group management–creation and configuration of protection groups. Mainly for local snapshot schedules and/or remote replication
5. Volume or snapshot management–for creating/changing/copying/deleting volumes or snapshots.
6. VMware ESXi and FlashArray–example workflows that combines a bunch of VMware and FlashArray workflows. Provision a new VMFS on a new FlashArray volume for example.

The individual workflows do a basic thing, they take in a parameter or two, either single values or some comma separated and then convert that into a REST call with JSON formatting and then submit it. The response is received as JSON and is then parsed into a vRO array object that can be easily referenced and passed between other workflows. The main goal is to handle the intricacies of REST for you.

Importing the package

Importing the package is simple. Go to the “Administer” view and click the “Import Package” button.

Now, locate the package file and import it. Accept the certificate. 

If the package or parts of it are already there it will not overwrite them. Otherwise just import it all as new (normal).

You will now see all of the workflows available in the workflow view.

Adding a FlashArray as a REST target

The first part to understand is that if you just run a workflow it will not work out of the box. You need to connect to a FlashArray first.

The FlashArray needs to first be stored as a REST object, this requires two steps which only need to be done once (unless the FlashArray changes somehow, like a new cert).

1. Import the certificate. This is a basic workflow that import the FlashArray certificate to the vRO cert store. This must be done first and only once per FlashArray.

You can see the certificate now listed in vRO under the general configuration:

The next step will be to add the FlashArray as a REST target. This also only needs to be done once per array. Start the “Add new FlashArray as REST target” workflow.

In this workflow you add the FlashArray connection parameters, such as a friendly name, a FQDN and some various other options (like a proxy if needed).

The new FlashArray REST object is now listed as an available target:

This is all of the pre-configuration you need to do. Everything else is at the time of connection.

Creating a FlashArray REST session

Now if you actually want to execute against a target you need to create a session. This might be one or two workflows. If your user already has a REST API token, you just need to create the session, if it doesn’t you need to create one first. This can all be done from vRO or of course in the FlashArray GUI if you want.

If your user already has a token you can authenticate a session to run your other workflows. To create a session include the “Create FlashArray REST Session” workflow in your own workflows. That will allow any later workflows talking to that same FlashArray target in the same parent workflow to speak to the FlashArray.

Please note that (by default and I will explain this in a later post) these sessions cannot span to other workflows. If you have one parent workflow that has the “Create session” workflow in it, all other workflows in that same parent will share that authentication session.

Short story, any workflow you create that uses one of the FlashArray workflows, make sure it includes the “Create FlashArray REST Session” one. You cannot just run the “Get FlashArray Volumes” by itself, you need to put it together in a parent workflow that also includes the “Create FlashArray REST Session” workflow.

The “Create FlashArray REST Session” requires you to choose your FlashArray target and give your username and password (the password is stored as a secure string). This will perform the API token exchange and authenticate the session. A successful connection will return your username and a session ID.

A valid response will look like below:

Video demo:

 For more color on how this process works, refer to this blog post.

https://www.codyhosterman.com/2015/11/understanding-vrealize-orchestrator-authentication-with-the-flasharray-rest-api/

Like I said before, just running the “Create FlashArray REST Session” by itself it not enough to authenticate another workflow. Look for upcoming posts on how to combine this with another workflow! In the meantime, here is a video demo about what I mean:

Here is a video demonstration of provisioning a new VMFS with a workflow. This workflow includes many of the basic workflows included in the package, it does the following:

• Takes in a cluster of your choice in a vCenter
• Takes in a FlashArray host, a volume name and a capacity
• Finds the WWNs of the hosts in the cluster
• Gets the configured hosts on the FlashArray
• Compares the WWNs from ESXi and tries to make a match to a host on the FlashArray
• If it finds matching hosts it finds the host group they are in
• It creates the volume and adds it to the host group
• Rescans the cluster and format the volume as VMFS

Don’t forget to register and come to the Pure Storage//Accelerate conference March 14th and 15th! I will be demoing this and more vRealize and FlashArray goodness.