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.
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.
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.