In order to address some of the limitations with the original Nimble plug-in for UCS Director ( Lack of rollback, no inventory, etc…), I have developed a library of workflows, workflow tasks and script modules that communicate directly with the new RESTful API available in Nimble software version 2.3 and beyond.
A brief description of the new functionality that I have provided, along with the structure of my work is detailed in the following text. The workflows themselves are attached to this post for your availability.
Firstly, a demonstration of the workflow tasks in action.
Example catalogue items:
UCS Director service end user logs in and requests a new Nimble volume. Notice how the user can select from a dynamically created list of values for the performance policy:
For this example, the user chooses the ‘Exchange 2007 data store’ performance policy and decides that the volume should be encrypted and pinned in the cache:
The volume gets successfully created:
and the service request log (As viewed by an admin) confirms this:
[INFORMATIONAL] MAIN(): Successfully created volume myExchangeVolume001.
If checked via the Nimble native GUI, it can be seen that the volume has been created, that it employs the appropriate performance policy and is both encrypted and pinned:
As soon as the volume has been created, the list of values (LOVs) for the volumes inventory is immediately updated in order to allow further operations to be processed against it. For example, let’s take the newly created volume and associates it with a volume collection. Notice in this next workflow, how both the volume and volume collection information is supplied dynamically and that no manual typing is required.
Once again, this completes successfully.
The Nimble native GUI reflects this change in the volume information.
Now, let’s add a few snapshots to the newly created volume. To make things interesting, we’ll add a mixture of snapshots that are online, offline and writable. This will show the intelligence of the ‘Delete Volume’ task that will be shown later.
As before, these changes are all reflected correctly within the native Nimble GUI:
At this point, we can show the power of UCS Director. Next, I am going to roll back the original ‘Create Volume’ workflow task. Were you to remove this manually via the Nimble GUI, then the online snapshots would all need to be taken offline, the volume would need to be disassociated from its volume collection and the volume itself would also need to be taken offline before being deleted. UCS Director can manage this in a smooth single step. Like so:
The service end user selects the ‘Create Volume’ service request and chooses for it to be rolled back.
What appears to be a simple ‘Delete Volume’ operation actually takes quite a lot into account:
An examination of the service request log (As admin) shows exactly what is going on:
[INFORMATIONAL] MAIN(): Found volume myExchangeVolume001
[INFORMATIONAL] MAIN(): Volume myExchangeVolume001 has 2 online snapshots.
Other tasks are included in the attached library to enable operations such as adding volumes to volume collections, adding initiator groups, adding initiators to initiator groups as well as mapping volumes to initiator groups.
Should you be interested in understanding how this functionality is implemented, please import the attached workflow file and examine the following locations:
With regards to the ‘NimbleREST_Nimble_Inventory_Service’ custom workflow task above, I have it configured as a scheduled task that runs every 5 minutes. This ensures that the LOVs are kept up to date in the event of infrastructure being configured outside of UCS Director (Via the Nimble GUI for example).