Skip to content
Python SDK for configuration and monitoring of F5® BIG-IP® devices via the iControl® REST API.
Branch: development
Clone or download
Latest commit 85f4866 Feb 12, 2019
Type Name Latest commit message Commit time
Failed to load latest commit information.
devtools Adds hard timeout for management initialization (#1333) Nov 30, 2017
docs Shorten example token for readability's sake and add missing ) in exa… Sep 25, 2018
f5-sdk-dist bump release (#1504) Aug 22, 2018
f5 Issue #1517 - Remove SIGALRM signal Feb 9, 2019
f5sdk_plugins fix flake8 Jan 11, 2017
.git-commit-template.txt Update commit template to ensure that issues are closed when the pull… Dec 5, 2015
.travis.yml - fixed #310 Mar 28, 2016
LICENSE Fixes: Issue #11 Structure the repo according to the team template Nov 18, 2015
RELEASE Tracked By: Oct 27, 2015 adding back in on this branch using the updated text (Fixes May 2, 2016
VERSION Bump version to production/stable. Jul 6, 2016
requirements.test.txt Issue #1487 - Fix issue with Node FQDN required parameters (#1492) Jul 30, 2018
setup.cfg Minor fixes Sep 13, 2017
setup_requirements.txt Adds debug call tracing to the sdk Jan 25, 2018



Build Status Documentation Status Slack


This project implements an SDK for the iControl® REST interface for BIG-IP®. Use this library to use python to automate a BIG-IP® via its REST API.


Please see the project documentation on Read the Docs:


$ pip install f5-sdk


If you are using a pre-release version you must use the --pre option for the pip command.


from f5.bigip import ManagementRoot

# Connect to the BIG-IP
mgmt = ManagementRoot("", "admin", "somepassword")

# Get a list of all pools on the BigIP and print their name and their
# members' name
pools =
for pool in pools:
    for member in pool.members_s.get_collection():

# Create a new pool on the BigIP
mypool ='mypool', partition='Common')

# Load an existing pool and update its description
pool_a ='mypool', partition='Common')
pool_a.description = "New description"

# Delete a pool if it exists
if'mypool', partition='Common'):
    pool_b ='mypool', partition='Common')

Design Patterns

I intend the SDK to be easy to use and easy to hack. These overarching goals have a strong influence on my thinking when I am reviewing contributions, this means it is in their own interest that I make them as explicit as possible!

The original interface specification was given to me by Shawn Wormke, who I believe was influenced by the Jira and Django projects. At the time I was reading Brett Slatkin's 'Effective Python', and I tried to follow its advice where possible.

List of Patterns For Contributing Developers

  1. Hack this list to make it more correct/complete

    For list additions assign @zancas as the PR reviewer.

  2. The call operator () means: "Try to communicate with the device."

    This is a strong contract we offer the consumer of the SDK. If an SDK function is invoked with the call operator () the program is initiating a communication with the device. That communication may fail before reaching the wire, but it has nonetheless been initiated. Conversely, if an SDK user evaluates an SDK expression that DOES NOT invoke the () call operator, then the SDK does NOT initiate a communication with the device. Any extension to the SDK that is not consistent with this contract is unlikely to be incorporated into the supported repository.

  3. The SDK is stupid

    The SDK doesn't decide things for the consumer, it's simply an interface so that Python programs can manipulate device resources without implementing custom URI/HTTP/network logic. Implications:

      The consumers of this library are themselves Python programs. The Application programmer must say what they mean in their SDK-using program. It violates a critical separation of concerns to add default values to the SDK. Don't do it! (Unless you have a good reason.)
    2. Failures generate exceptions
      If the SDK enters a surprising or unexpected state it raises an exception. That's it. It's not generally up to the SDK to implement decision logic that handles edge-cases.. EXCEPT where the SDK is smoothing known issues in the device REST server. (See below.)
    3. The SDK never interprets responses
      It just records whatever response the device returns as attributes of the relevant object. (Except where handling significant inconsistencies in the device interface.)
  4. public-nonpublic pairs

    e.g. 'create' and '_create' XXX add content here.

  5. Handle known issues in the device REST server.

    The SDK intends to provide a rational interface to consumers that does the right thing. This means that one case where it does NOT simply do the stupid thing is when it handles a known idiosyncrasy in the device REST server. For example, some? resources ignore 'disable' and 'enable' configuration options when they are set to 'False'. Rather than force a consumer to learn about this quirk in the server, the SDK guesses that '"disable": False' means '"enable": True' , and submits that value on the consumers behalf.

  6. Implement-Reimplement-Abstract

    Solve the problem concretely and simply, if the same problem arises again, solve it concretely, then take the two concrete solutions and use them as your specification to generate an abstraction. In the SDK this usually goes something like this:

    1. Add logic to a concrete subclass
    2. Add similar logic to another concrete subclass
    3. Create a new method in a mixin or Abstract '' base class and have both concrete subclasses inherit and use that method.



Python API for configuring objects on a BIG-IP® device and gathering information from the device via the REST API.

Filing Issues

See the Issues section of Contributing.


See Contributing


Before you open a pull request, your code must have passing pytest unit tests. In addition, you should include a set of functional tests written to use a real BIG-IP device for testing. Information on how to run our set of tests is included below.

Unit Tests

We use pytest for our unit tests.

  1. If you haven't already, install the required test packages listed in requirements.test.txt in your virtual environment.

    $ pip install -r requirements.test.txt
  2. Run the tests and produce a coverage report. The --cov-report=html will create a htmlcov/ directory that you can view in your browser to see the missing lines of code.

    py.test --cov ./icontrol --cov-report=html
    open htmlcov/index.html

Style Checks

We use the hacking module for our style checks (installed as part of step 1 in the Unit Test section).

$ flake8 ./


Copyright 2014-2016 F5 Networks Inc.


Apache V2.0

Licensed under the Apache License, Version 2.0 (the "License"); you may not use this file except in compliance with the License. You may obtain a copy of the License at

Unless required by applicable law or agreed to in writing, software distributed under the License is distributed on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the License for the specific language governing permissions and limitations under the License.

Contributor License Agreement

Individuals or business entities who contribute to this project must have completed and submitted the F5 Contributor License Agreement to prior to their code submission being included in this project.

You can’t perform that action at this time.