Forum Discussion

wholroyd_98274's avatar
wholroyd_98274
Icon for Nimbostratus rankNimbostratus
Dec 23, 2009

Does the GUI use iControl behind the scenes?

There seems to be some confusion on my end as to how the GUI makes the necessary updates behind the scenes and was wondering if it uses the server side iControl API/portal to do it's work.

 

 

I'd like to use the iControl API for remote management, however, I'd also like to know what kind of new issues might popup and what other vectors to expect for security/performance/etc reasons.

 

 

I tried doing a search in both the forums and wiki, but wasn't able to find anything. Thanks in advanced for your input!

7 Replies

  • The answer is yes and now. There are a few places, such as the key management, where the GUI uses the iControl under the seams. But, for the most part both iControl and the management GUI use the same underlying database abstraction layer for data access.

     

     

    What exactly are your concerns? iControl is a proven technology that has been included in the products since 2001. That's not saying it can't be abused. If you had 100's of users hitting the GUI at once then there could be impacts as well. As an API, we've done some things in the behavior with iControl so that it will minimize impacts. For instance, the GUI will auto-save the config to disk after every change. We removed this from iControl so that the calls wouldn't incur the multi-second delay (depending on the size of the config). You must use the ConfigSync.save_configuration method when you are ready to commit your changes to disk. In this way, iControl actually has less overhead than the GUI.

     

     

    Let me know if you have any further concerns and I'll do my best to alleviate them B-).

     

     

    Cheers!

     

     

    -Joe
  • I'm just essentially trying to ensure that by using iControl for remote management, that there wouldn't be any issues with memory or other resource utilization pressures. I had run into some resource exhaustion before (I can't quite recall the feature that caused it at the moment, it was a while ago) and have fears about reproducing that particular type of issue with iControl. Since then I've been paranoid about introducing any other changes.
  • Do you have an idea of the specific activities you'll be using iControl for? Generally speaking there's not much to be concerned about, but it's always good to qualify things as you're doing.

     

     

    Any specifics you may have could help home in on any potential issues.

     

     

    -Matt
  • The end goal that I'd like to achieve through iControl is to view all the nodes, all the pools/vips, and be able to correlate the overall status of the nodes globally and per pool/vip so I can produce a list of servers that are out of service or were removed automatically by the F5 for failed health probes. I haven't found it yet in the documentation, but I'd also like to see if there is a way to extract auditing information from iControl to see whom has performed what in the GUI. I'd also like to remove and return servers from/to service using iControl so I can place some automation around patching, upgrading, or other types of maintenance.

     

     

    I don't see any uses for iControl outside of these actions at this time (maybe down the road, but this is my current project). I think we'll stick to making configurations manually for now since it's not very often that we have to change anything.
  • Do you have a feel for how many virtuals/pools/nodes we're talking about? What you're looking to do isn't particularly heavy (fetch list of pools/members, check status, map to virtuals) but if you've got hundreds of objects you're pulling it may well be worth some off-hours testing of an iControl script.

     

     

    -Matt
  • I'll have to check for a deffinate amount, but I'd say at -MOST- around 1200 nodes and possibly 200 virtuals/pools. Those are also generous guesses for 'growth'.