f5 connection string with pycontrol

Andy: to call against multiple systems, you've got a few options. Note that the actual transport is good ol' urllib2, handled by suds - nothing too fancy there. Your design concerns are valid, because it's super inefficient to call against and instantiate a BigIP object for each one of your systems. In a large environment this wouldn't scale well at all. Fortunately though, you've got some options.

 

 

1) Instantiate a single BIGIP object, then call against the suds.set_options() method to change the location - it's something that you can change on the fly, and it'll allow you to use a single pycontrol object to call against multiple systems. This has a distinct disadvantage of blocking for each request/response cycle though. This means that you'd loop over a set of systems, make a call against each one, etc. But you have to wait for one call to finish before you can make the next. This is the simplest option, though...

 

 

2) Use threads. This is much more complicated code wise, but it gives you real concurrency so you can call against multiple systems at the same time, without blocking. For this, suds exposes a super handy method, clone() that will clone an object. Then you simply call set_options(location='https:///iControl/iControlPortal.cgi') against each cloned object that you want. This method has a bunch of advantages and works well, but programming threads is complicated.

 

 

3) Use the multiprocessing module via the exact same techniques that you'd use for threads.

 

 

4) Use something like the AWESOME celery module for a formal job queue with nice Django integration. This is likely to change your design in pretty major ways though.

 

 

At the heart of all of these techniques though is your set_options() call. This method works for ALL suds options and is super handy. print out the options for your object and you'll see all of the stuff that is exposed, e.g. 'print b.LocalLB.Pool.suds.options'.

 

 

This should keep you busy for a while!

 

 

-Matt