Forum Discussion

Michel_van_der_'s avatar
Icon for Nimbostratus rankNimbostratus
Jun 18, 2003

General comments/observations regarding iControl



I've spent a bit of time with the iControl sdk, and, as


witnessed in this developers portal, ran into some challenges


and issues. I thought it might be worthwhile to line out most


of my learnings over the last week or so in one message. Not


sure if F5 will do anything with it, but hey, why not at least


let you know! I only use BigIPs, so all my comments are specific


to that device. I also only use V4.2PTF6, so again, all my


comments are specific to that version of the software.



Overall Thoughts


First off, I think that iControl as a concept is very good.


After thinking about how we like to use the F5s we currently


have, I can see that we'll have some options to integrate the


F5s we use more closely into our total service offerings, by


e.g. providing application intelligence, which can help the F5


devices more effectively manage the services 'behind' it. I'm


mostly thinking about a more application centric ability to


enable/disable nodes. So e.g. when a node becomes unavailable


for application reasons, the application can simply notify the


F5 device it's wants to be disabled. Once complete, we can





Secondly, I feel iControl delivers, but it still needs a little


polish, mostly in the documentation arena. Although this forum


is fantastic, I think all of my questions, save one or two,


should have been handled through better documentation. Parameter


documentation like 'set_server_certificate_mask' .. 'Sets the


bitmask to specify how the server certificate is handled' is


obviously not at all helpful.



What I used it for


My current use of the sdk focuses around a challenge different


from what I outlined earlier. This challenge was something that


I hope, eventually, ISMan will address. I have a simple web


application, built with LAMP (Linux, Apache,


MySql, Perl), which contains the 'configuration'


of the various F5 BigIPs we have on our network. This is not


the configuration from the F5 appliance perspective, it's the


configuration that describes how we want the devices to work


for our environment. We don't even use 50% of the devices'


flexibility; we do however do some interesting stuff with rules


and pools. Given that complexity, we want to be able to configure


and deploy the devices from a central location, reliably and


identically (as much as you can within the network config off





The original version of the application than takes the specified


configuration, which contains mostly IP addresses, pools, rules


and monitor definitions and turns it into a large bigpipe command


file (i.e. shell script). I can then take that command file to a


BigIP device, which has only the basic 'config' script run on it


and finish the configuration.



My goal was to use the iControl sdk and rewrite the application


to not use any command file at all. In a sense I was not


successful, since I wasn't able to do that. This had mostly to


do with the fact that we use forwarding pools (not supported


with iControl today, posted by locph, May 28) and some strange


snat mappings. So, today, the app still generates a command


file, although much smaller and only the base config data.



In another sense I was successful, since after the base config


is done, I can now manage the configuration remotely (i.e.


adding pools, changing pools, enabling/disabling nodes, adding


SSL, etc.). And, furthermore, I was able to add some very


useful functionality, such as the ability to search which F5


manages a particular back-end server, and allow for


enabling/disabling the device. Also, the ability to


enable/disable from a central location is extremely valuable.



What does iControl need today


Documentation For someone who knows the F5 device inside


out, perhaps the documentation is sufficient. It wasn't for


me. Even having a pretty good grasp on the bigpipe command


set, I sometimes struggled to find the right call. There are


discrepancies between what the bigpipe command set and the GUI


can do and what iControl delivers. Since most of the other


documents in the F5 set use the GUI/bigpipe, this is a serious


shortcoming. BTW, I think the GUI and the bigpipe command set


have the same problem. It's hard to understand how he GUI maps


to the bigpipe command set at time as well!



Another issue is the differences in versions. Details of the


changes between versions is very valuable. If something is not


supposed to work in the version I'm using, I'd like to know


about it (and when it was fixed off course!).



Consistency Some of the calls are not extremely consistent.


Sometimes there are bulk calls, sometimes there are not. Some


things have decent descriptions, some don't. It would be nice


if all of the top level objects had descriptions with some


example code, similar to how Sun does their JavaDocs. E.g. if I


go to javax.swing, it tells me what it is, where the


programmer's guide is, pointers to tutorials, etc.



SpeedI used SOAP/Perl. Mostly because that's what the


original app was written in. However, it is slow. SOAP::Lite


can perhaps be optimized (?), but overall, it feels slow.


Especially since you need to use https (which is a good


thing), some operations are painfully slow. I don't want to


optimize my calls to increase speed, it should be inherently





Fine Grained AccessNot sure if I missed it, but near as


I can tell, you can only use two authorization models. All or


nothing. Something more fine-grained would be nice.



And Finally


These observations are meant to be constructive. I think


iControl is a great concept, it really allows people that use


them to integrate them into the complete application and


data-center portfolio, without having to wait for F5 to provide


all of the tools/GUIs that would be needed otherwise. I'm


hoping my questions and observations will help it grow into an


even better product.
No RepliesBe the first to reply