Forum Discussion

Payal_S's avatar
Payal_S
Ret. Employee
Apr 20, 2016

Process's to check for before running a REST call

Summary of issue: Trying to run a REST call after a VE or HW is booted up, but not sure what process to check for to make sure that the system is ready to accept REST calls (11.5/11.6 BIG-IP version)

 

Can someone please point to 1) What process to check for before running a REST call 2) What other process's can we check for to make sure our BIG-IP is ready in general (all process's are UP and the system is ready with respect to all aspects. CLI/UI/Passing traffic etc.

 

This is a big blocker for automating with BIG-IP because right now we are waiting for 3-4 minutes after the VE/HW boots and then trying to issue commands and are intermittently hitting REST connection issues.

 

Any suggestions?

 

Thanks Payal

 

2 Replies

  • JG's avatar
    JG
    Icon for Cumulonimbus rankCumulonimbus

    There could be a lot of things to check to be 100% sure. One thing I'd try would be:

    curl -k -u admin:admin -X GET 'https://my_mgmt_IP_addr/mgmt/tm/sys/failover'
    

    which outputs something like following:

    {"kind":"tm:sys:failover:failoverstats","selfLink":"https://my_host/mgmt/tm/sys/failover?ver=11.6.0","apiRawValues":{"apiAnonymous":"Failover active for 34d 21:12:21\n"}}

    by which you come to know that the device is "active", and then you can go on do a transactional operation.

    You could also try a test (but real) operation on a dummy object to see if it works for more certainty.

  • There probably are many ways.

    I just check if the GUI management interface is operational - is the login information requested? For that a normal GET request to

    https://mgmt-ip/
    will suffice, no API authentication needed.

    Depending on situation, I also use the failover API call Jie mentioned. Typically for scripts that are very CPU-intensive for the BigIP (ASM policy exporting task as an example). In case of CPU-intensive tasks, I want to target the API calls towards Standby, and not the Active unit. For tasks that create new configuration, you can use the same call to look for Active unit.

    Apart from these two commands, I haven't used anything for the purpose. No problems so far.