Tech Tip: Intro to iControl Information Mining

Introduction
Any large development library has some choices to make about implementation, and iControl is no exception. A library is designed to give others access to routines that you have written (in our case, BIG-IP interfaces), and when the public-facing interfaces are defined, the designers have to try and foresee how the majority of users will want to use the library. 

With iControl for BIG-IP, the design was approached as what I call “Building Block Minimalist”. That’s where you build the very bottom layer of interface and allow users to put the parts together to get what they need.

The opposite end of this approach is what I call the “Business Block Maximalist” approach (again, my name), where each routine represents many internal calls to create a response that has everything you may want in it – usually focused upon a given business process, hence the name I use. 

While there are proponents of both approaches, neither is wrong. I personally prefer the middle-of-the road approach, but that’s a blog topic. The strength of the Building Block Minimalist approach is reuse – a node address will always be a node address, so you can write routines to get them and reuse those routines. The weakness is that you generally have to write a lot more code to perform a simple function. The strength of the Business Block Maximalist approach is less code as long as you’re in the model the authors are thinking of. For example, a routine to get all of the pertinent data about a Pool would give you nodes in the pool, status of the pool, etc. in a single call. The weaknesses of this approach are that it takes a lot more bandwidth to send all of this data, and what if all you needed was the name? Reuse is generally high, unless you want to do something the authors weren’t thinking of, then it breaks down rapidly. This is a common problem in Microsoft products – they want to make it easy for you, but in doing so they have to direct you into certain development paths.

So what does all of this mean to you? It means that there are some relationships you need to be aware of. I’ll touch on the them here, these are trends that you can rely upon across all of the iControl interfaces. 

Get a List
Each interface has a get_list() method that allows you to get a basic list of that type. For example, LocalLB::Pool.get_list will return a list of the pools on your BIG-IP. Since all of the items below require a list of the base type (Pool names in our example), this is the first item you should call, unless you already know the pools you’re interested in. 

Details
All of the details are provided in separate routines. What those details are varies based upon the type, but status is a common one – is the item enabled? To find the status, call the get_status routine with a list of the items returned in get_list as the parameter. In our example, LocalLB::Pool.get_status(listOfPoolNames) will do it. 

Other items that are less obvious
Sometimes you want to know something that is not so obvious. What pools a given node belongs to, for example, is not possible through the node interface. In that case, you will have to go to the other interface (Pools in this example), and ask it to help you find the node in question. In the case of finding out which pools a Node belongs to, you need to loop through the list of Pools and ask each for its list of Nodes, then look for your Node in the list. Inefficient? Yes, but the design of iControl is around the objects it supports. A Pool contains Nodes, Nodes don’t know directly about Pools. 

Other Options
If this is more than you want to do, we have taken care of some of this for you in the iControl Wrappers (available in the Labs section of DevCentral), making the calls for you in the common cases like the example above - “what Pools contain this Node”. As time goes on we will wrap more of these items, and hold out hope that the most frequently used ones will one day be moved into the API directly.

Conclusion
iControl is very consistent. Once you learn how it was designed, you can reuse that knowledge across types. If you need some information that your current object doesn’t provide, think about the other object involved. Chances are you can get the information you’re after by coming at it from that other object – like nodes and pools.