UCSD Controlling the Nimble RESTful API with UCS Director Custom Workflow Tasks

Version 2

    Important Note:

    Minimum UCS Director version is 5.3.

    Minimum Nimble array version is 2.3.




    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.

    Screen Shot 2015-08-04 at 18.00.32.png


    Example catalogue items:

    Screen Shot 2015-08-04 at 18.01.34.png


    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:

    Screen Shot 2015-08-04 at 18.02.21.png


    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:

    Screen Shot 2015-08-04 at 18.03.15.png


    The volume gets successfully created:

    Screen Shot 2015-08-04 at 18.04.07.png


    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:

    Screen Shot 2015-08-04 at 18.05.04.png


    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.

    Screen Shot 2015-08-04 at 18.05.55.png


    Once again, this completes successfully.

    Screen Shot 2015-08-04 at 18.06.43.png


    The Nimble native GUI reflects this change in the volume information.

    Screen Shot 2015-08-04 at 18.07.48.png


    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.

    Screen Shot 2015-08-04 at 18.19.28.png

    Screen Shot 2015-08-04 at 18.20.00.png

    Screen Shot 2015-08-04 at 18.20.07.png


    As before, these changes are all reflected correctly within the native Nimble GUI:

    Screen Shot 2015-08-04 at 18.21.45.png


    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.

    Screen Shot 2015-08-04 at 18.22.25.png


    What appears to be a simple ‘Delete Volume’ operation actually takes quite a lot into account:

    Screen Shot 2015-08-04 at 18.23.29.png


    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.

    [INFORMATIONAL] MAIN(): Taking snapshot mySnap1 offline.

    [INFORMATIONAL] MAIN(): Snapshot mySnap1 taken offline successfully.

    [INFORMATIONAL] MAIN(): Taking snapshot mySnap3 offline.

    [INFORMATIONAL] MAIN(): Snapshot mySnap3 taken offline successfully.

    [INFORMATIONAL] MAIN(): Volume myExchangeVolume001 is online. Taking offline.

    [INFORMATIONAL] MAIN(): Volume myExchangeVolume001 successfully taken offline.

    [INFORMATIONAL] MAIN(): Volume myExchangeVolume001 is protected. Disassociating...

    [INFORMATIONAL] MAIN(): Successfully unassociated volume myExchangeVolume001 from volume collection.

    [INFORMATIONAL] MAIN(): Successfully deleted volume myExchangeVolume001.


    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:



    Screen Shot 2015-08-04 at 18.24.25.png


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



    Custom Workflow Tasks:

    Screen Shot 2015-08-04 at 18.25.25.png


    Script Modules:

    Screen Shot 2015-08-04 at 18.26.14.png


    For any questions regarding the above, please email rwhitear@cisco.com.