Consuming WFA Resources from Ansible

Configuration management and Infrastructure as Code are very hot topics these days.  The faster you can configure, provision and present your operations resources, the faster you can meet customer needs.  NetApp has released new and improved Ansible modules for ONTAP and we are working on covering more of the NetApp family of products.

However, what do you do if you have already invested a lot of time and money in OnCommand Workflow Automation(WFA)? While WFA has its advantages, such as strong user control, automatic resource selection, and a deep pool of available workflows, it also has disadvantages.  With WFA, customization doesn’t exist out of the box and often requires professional services work to match your environment.  Additionally, connecting the provisioned storage to the host which needs to consume it using WFA is very difficult.

Ansible, on the other hand, is easy to customize for your environment right away, and it allows you to combine more than just NetApp resources in a single playbook.  A negative vs WFA though is you have to already know what resources you will be working with, aggregate names, volume names, cluster hostnames, etc.  What are sites that want to make the switch, but don’t want to lose all their work to do?

The solution is the Ansible URI module consuming the WFA REST API.  I am going to show three example playbooks that will demonstrate how to call WFA workflows from Ansible.

The three steps to using WFA from Ansible are:

  1. Get the UUID of the workflow – WFA workflows are referred to by UUID, so before we can interact with it via the REST API, we have to find the UUID for the named workflow we want to use.
  2. Run the workflow – this includes providing all of the inputs the workflow needs and invoking it.
  3. Get the status of the workflow job – the workflow is started asynchronously, which means that after we start it executing, we need to check with WFA to make sure that everything executes successfully.

Getting the UUID of the Workflow

 It would be too simple if you could just use the name of the workflow you wanted to call, but, unfortunately, the REST API requires the workflow UUID.  I want to get the UUID of the workflow “Create a Cron Schedule”.  Here is the playbook to get this workflow’s identifier.

The username and password are the username and password of my WFA user.  At line 7, workflow, update the line with the name of the Workflow you will want to run.  Running this playbook will generate an output that is the UUID for that workflow. This is a default workflow so feel free to try this playbook on your WFA server, updating for your username/password, and WFA URL.

Running a workflow

Now that we have the UUID of the workflow we want to run, we can use another playbook to actually send our variables and start the workflow.  Each workflow has its own set of input prompts that were configured and you will need to be able to provide data for each of them.  SQL queries don’t run for the REST API call, so if the information was selected that way, you will have to enter that by hand now. Here I run a playbook to create a volume using a custom workflow I created and already got the UUID for. See here for the documentation on WFA REST API calls to be used in the body section.

The output of this playbook is a job id that will be needed to look up the status of the workflow. Yes, looking up the status is the third playbook.

Getting the status of a job.

Take the job id from the previous step and replace the task variable in the example below.

This playbook will output the status code of the playbook.  If it has failed, you will need to go to WFA to figure out why.  The job status response will be one of the following: SCHEDULED, PENDING, EXECUTING, COMPLETED, FAILED, ABORTING, CANCELED, OBSOLETE, PAUSED, PLANNING

Summary

As you can see it is possible to call WFA from your Ansible setup.  Configuring most, if not all, of your WFA workflows in Ansible is very simple. This setup is a good stop gap to use as you convert your workflows entirely to Ansible playbooks using the NetApp modules.

I encourage you to give creating a playbook for your needs a try. We have example playbooks as well as people who would really like to talk to you about configuration management and Ansible at netapp.io and our Slack team.  I look forward to seeing you there!

David Blackwell on Linkedin
David Blackwell
Technical Marketing Engineer for OpenStack at NetApp
David is a twenty year IT veteran who has been an admin for just about every aspect of a DataCenter at one time or another. Currently he is the Technical Marketing Engineer for OpenStack at NetApp. When not working, or tinkering with new software at home, David spends most of his free time on his hobby of 3D printing.

Leave a Reply