Pool member status on F5 DNS objects via iControl REST

I got a question on how to retrieve the status of pool members on F5 DNS objects via the iControl REST interface. In the GUI you get fancy red, yellow, black, blue, and green painted circles, diamonds, squares, and triangles to communicate availability. At the command line, however, it’s harder to map that visual data. There are two important settings underlying an object’s availability: availability state and enabled state. You can see when using the field-fmt option on the tmsh command to show the pool member status that both GTM and LTM objects report the same data (the remaining fields are removed for brevity):

gtm pool pool gslb_pool_1:A {
    members {
        testvip:ltm3 {
            status.availability-state available
            status.enabled-state enabled
            status.status-reason Available
        }
    }
    status.availability-state available
    status.enabled-state enabled
    status.status-reason Available
}

ltm pool testpool {
    members {
        192.168.103.20:80 {
            status.availability-state available
            status.enabled-state enabled
            status.status-reason Pool member is available
        }
    }
    status.availability-state available
    status.enabled-state enabled
    status.status-reason The pool is available
}

Through the REST interface, both status fields are available in the LTM pool object. Calling the pool member and selecting on session and state, the following request returns the data as expected:

GET https://ltm3.test.local/mgmt/tm/ltm/pool/testpool/members/~Common~192.168.103.20:80?$select=session,state
{
    "session": "monitor-enabled",
    "state": "up"
}

However, these same status fields are not available on GTM pool/pool member REST objects. Calling a GTM pool member, the following request returns no information on monitor status (that's the availability-state field from above) but does indicate the enabled state, albeit unconventionally by changing the field name:

GET https://ltm3.test.local/mgmt/tm/gtm/pool/a/~Common~gslb_pool_1/members/~Common~ltm3:~Common~front_door
# when enabled:
{
    "name": "front_door",
    "enabled": true,
}
# when disabled:
{
    "name": "front_door",
    "disabled": true,
}

So if the information is not available directly from the REST interface, how do you get it? Well, you have options. The newest approach (and one I am currently investigating for things like this) is writing your own API via the iControl LX extensions. That's not the approach I'll take here, however. Instead, I'll use a tmsh script to return the appropriate data via a bash call from iControl REST.

The tmsh script is quite simple. It takes an argument for the type of GTM pool you wish to query, and then the pool name. It will then iterate through the members and return for each member the pool member name, its availability state, and its enabled state.

proc script::run {} {
    if { $tmsh::argc != 3 } {
      puts "A pool type and name must be provided"
      exit
    }
    set pool_type [lindex $tmsh::argv 1]
    set pool_name [lindex $tmsh::argv 2]
    foreach obj [tmsh::get_status /gtm pool $pool_type $pool_name detail] {
      foreach member [tmsh::get_field_value $obj members] {
        puts "[tmsh::get_name $member],[tmsh::get_field_value $member status.availability-state],[tmsh::get_field_value $member status.enabled-state]"
      }
    }
  }
    total-signing-status not-all-signed
}

Running the script from bash on the BIG-IP, I get the following results:

[root@ltm3:Active:Standalone] tmp # tmsh run cli script pool-status.tcl a gslb_pool_1
front_door:ltm3,available,disabled
testvip:ltm3,available,enabled
testvip2:ltm3,available,enabled

And finally, calling this with the F5 python SDK returns the same results:

>>> from f5.bigip import ManagementRoot
>>> mgmt = ManagementRoot('ltm3.test.local', 'admin', 'admin', token=True)
>>> ps = mgmt.tm.util.bash.exec_cmd('run', utilCmdArgs='-c "tmsh run cli script pool-status.tcl a gslb_pool_1"')
>>> ps.commandResult
u'front_door:ltm3,available,disabled\ntestvip:ltm3,available,enabled\ntestvip2:ltm3,available,enabled\n'

You can of course modify the tmsh script to return the data in a different format, I opted for quick and dirty here to model the problem and solution. Thanks go to community member Aaron Murray for the question and the inspiration, happy coding out there!