General comments/observations regarding iControl

Background

 

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

 

re-enable.

 

 

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

 

course).

 

 

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

 

quicker.

 

 

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.