iCall Triggers - Invalidating Cache from iRules

iCall is BIG-IP's all new (as of BIG-IP version 11.4) event-based automation system for the control plane. Previously, I wrote up the iCall system overview, as well as an article on the use of a periodic handler for automating backups. This article will feature the use of the triggered iCall handler to allow a user to submit a http request to invalidate the cache served up for an application managed by the Application Acceleration Manager.

Starting at the End

Before we get to the solution, I'd like to address the use case for invalidating cache. In many cases, the team responsible for an application's health is not the network services team which is the typical point of access to the BIG-IP. For large organizations with process overhead in generating tickets, invalidating cache can take time. A lot of time. So the request has come in quite frequently..."How can I invalidate cache remotely?" Or even more often, "Can I invalidate cache from an iRule?" Others have approached this via script, and it has been absolutely possible previously with iRules, albeit through very ugly and very-not-recommended ways. In the end, you just need to issue one TMSH command to invalidate the cache for a particular application:

tmsh::modify wam application content-expiration-time now

So how do we get signal from iRules to instruct BIG-IP to run a TMSH command? This is where iCall trigger handlers come in. Before we hope back to the beginning and discuss the iRule, the process looks like this:

Back to the Beginning

The iStats interface was introduced in BIG-IP version 11 as a way to make data accessible to both the control and data planes. I'll use this to pass the data to the control plane. In this case, the only data I need to pass is to set a key. To set an iStats key, you need to specify :

• Class
• Object
• Measure type (counter, gauge, or string)
• Measure name

I'm not measuring anything, so I'll use a string starting with "WA policy string" and followed by the name of the policy. You can be explicit or allow the users to pass it in a query parameter as I'm doing in this iRule below:

when HTTP_REQUEST {
  if { [HTTP::path] eq "/invalidate" } {
    set wa_policy [URI::query [HTTP::uri] policy]
    if { $wa_policy ne "" } {
      ISTATS::set "WA policy string $wa_policy" 1
      HTTP::respond 200 content "App $wa_policy cache invalidated."
    } else { HTTP::respond 200 content "Please specify a policy /invalidate?policy=policy_name" }
  }
}

Setting the key this way will allow you to create as many triggers as you have policies. I'll leave it as an exercise for the reader to make that step more dynamic.

Setting the Trigger

With iStats-based triggers, you need linkage to bind the iStats key to an event-name, wacache in my case. You can also set thresholds and durations, but again since I am not measuring anything, that isn't necessary.

sys icall istats-trigger wacache_trigger_istats {
    event-name wacache
    istats-key "WA policy string wa_policy_name"
}

Creating the Script

The script is very simple. Clear the cache with the TMSH command, then remove the iStats key.

sys icall script wacache_script {
    app-service none
    definition {
      tmsh::modify wam application dc.wa_hero content-expiration-time now
      exec istats remove "WA policy string wa_policy_name"
    }
    description none
    events none
}

Creating the Handler

The handler is the glue that binds the event I created in the iStats trigger. When the handler sees an event named wacache, it'll execute the wacache_script iCall script.

sys icall handler triggered wacache_trigger_handler {
    script wacache_script
    subscriptions {
        messages {
            event-name wacache
        }
    }
}

Notes on Testing

1. Add this command to your arsenal - tmsh generate sys icall event <event-name> context none</event-name> where event-name in my case is wacache. This allows you to troubleshoot the handler and script without worrying about the trigger.
2. And this one - tmsh modify sys db log.evrouted.level value Debug. Just note that the default is Notice when you're all done troubleshooting.