0% found this document useful (0 votes)

796 views287 pages

f5 Ansible

This project implements Ansible modules for the BIG-IP platform from F5 Networks. The modules allow users to create, edit, update, and delete configuration objects on a BIG-IP. The documentation explains how to install dependencies and run an example playbook to create a pool, add nodes, and assign a virtual server.

Uploaded by

arvind

We take content rights seriously. If you suspect this is your content, claim it here.

Available Formats

Download as PDF, TXT or read online on Scribd

0% found this document useful (0 votes)

796 views287 pages

f5 Ansible

Uploaded by

arvind

We take content rights seriously. If you suspect this is your content, claim it here.

Available Formats

Download as PDF, TXT or read online on Scribd

You are on page 1/ 287

F5 Ansible Documentation

Release 1.0.0

F5 Networks

Nov 17, 2017

User Documentation

1 Getting Started 3

2 Version support 5

3 Run your first BIG-IP playbook 7

4 Connection or delegation 11

5 Install unstable F5 Modules 15

6 Filing Issues 17

7 Module Index 19

8 F5 Networks Contributor License Agreement 183

9 Getting involved 185

10 Guidelines 189

11 Architecture 193

12 Code Conventions 195

13 Upstreaming 209

14 Upstreaming Process 211

15 Writing a Module 213

16 Deprecating Code 225

17 Code Conventions 227

18 Dealing with “replace all” 233

19 Deprecating functionality 235

20 pycodestyle 237

i
21 Design Patterns 239

22 Class variables 241

23 Common classes 243

24 Defaulting to None 245

25 What is the layer of @property decorators all about? 247

26 Why are they not all setters? 249

27 Use the module_utils test suite to verify AnsibleF5Parameters classes 251

28 Never import * 253

29 The Changes class 255

30 The Difference class 257

31 API Map Adapter 259

32 1-to-1 Adapter 261

33 Securing sensitive information 263

34 SSH functionality for modules 269

35 Issue Management 271

36 Pulling Docker Containers 273

37 Allow new admin access of private data 275

38 Parameter classes 281

ii
F5 Ansible Documentation, Release 1.0.0

This project implements a set of Ansible modules for the BIG-IP platform from F5 Networks.
You can use these modules to create, edit, update, and delete configuration objects on a BIG-IP.
The code is open source, and . Additionally, some modules have been promoted to the and .

User Documentation 1
F5 Ansible Documentation, Release 1.0.0

2 User Documentation
CHAPTER 1

Getting Started

This document explains how to begin using the F5 Ansible modules.

Note: F5 Ansible modules are not currently supported by F5.

1.1 Install Python

Install the latest version of Python (2.7 minimum) if you do not already have it.
•

1.2 Install Ansible

Then, install Ansible (2.2.0 minimum):

•
F5 recommends that you install Ansible by using virtualenv/pip. For an example, see virtualenv.
•

1.3 Install Ansible Dependencies

In addition to Ansible, you should install a few additional Python modules.

• f5-sdk
• bigsuds
• netaddr
• deepdiff

3
F5 Ansible Documentation, Release 1.0.0

At minimum, you should add f5-sdk.

You can install these by using pip (either globally or within a virtual environment), for example:

(myansible) $ pip install f5-sdk bigsuds netaddr deepdiff

To view dependencies for a specific module, view the module’s Documentation > Requirements section.

4 Chapter 1. Getting Started

CHAPTER 2

Version support

F5 develops the Ansible modules in tandem with the REST API, and newer versions of BIG-IP provide better support.
F5 has tested these versions of BIG-IP with the Ansible modules:
• 12.1.0
• 12.0.0
• 11.6.0
You may need a later version, depending on what the REST functionality needs.
Note: F5 Ansible modules are not currently supported by F5.

2.1 Get assistance

If you need help with anything related to these modules, F5 recommends that you open an issue .
When communicating with F5 on the Issues page, use the github user interface, rather than email.
You should not expose the name of your company when communicating an issue in a public forum.
If you need more in-depth technical assistance, you’re free to ask us to ping you offline and we can handle things there.

2.1.1 Credentials and secret things

You should not expose credentials in a github issue.

We do not need any of the following task arguments to debug your issue:
• user
• password
• server
• server_port

5
F5 Ansible Documentation, Release 1.0.0

When you submit an issue:

• Do not provide this information (leave it empty with quotes “”)
• Provide placeholders for this information (such as “admin”, “secret”, and “lb.mydomain.com”)
F5 does not need this information to provide you with assistance.

2.2 Is a module supported?

Remember that, ultimately, this repository contains experimental code.

However, with that said, there is a quick way to figure out if a particular module works on a particular platform.
First, look for your modules in the tests/ directory.
Each module has a doc block which includes a “Tested platforms” section. For example:

# Tested platforms:
#
# - NA
#

The above doc block tells you that F5 has not yet tested this particular module on any platforms. This is a fairly safe
bet that the module is not complete yet.
Therefore, F5 does not recommend filing bugs against this module.
Here is another example:

# Tested platforms:
#
# - 11.6.0
# - 12.0.0
#

This module specifies the versions of BIG-IP that F5 has tested. Therefore, you can consider this module to be
“complete” and ready for use.
You can file bugs against these modules.

6 Chapter 2. Version support

CHAPTER 3

Run your first BIG-IP playbook

Follow this tutorial to create a pool, add two nodes to that pool, and assign a virtual server to serve requests to the
nodes in the pool.
You can create your own yaml file to use as a playbook, or follow along with .
Begin by placing the following in your site.yaml:
---

- name: Create a VIP, pool, pool members and nodes

hosts: big-ip01.internal
connection: local

Your BIG-IP is probably not called big-ip01.internal. It might be a different hostname or even an IP address.
Whichever it is, place it in the hosts line.

3.1 Add a pool

A pool represents a collection of resources. These resource typically deliver a service that is identical. By assigning
them to a pool, the BIG-IP is able to distribute requests among them.
Add the following to your site.yaml to create a pool called web:
tasks:
- name: Create a pool
bigip_pool:
lb_method: "ratio_member"
name: "web"
password: "admin"
server: "big-ip01.internal"
slow_ramp_time: "120"
user: "admin"
validate_certs: "no"
delegate_to: localhost

7
F5 Ansible Documentation, Release 1.0.0

3.2 Add two nodes

Now you want to create the nodes in your BIG-IP configuration. Nodes represent the actual devices on your network.
They could be physical gear, VMs, or other devices.
To add the two nodes, put the following in your site.yaml:

- name: Create node1

bigip_node:
host: "10.10.10.10"
name: "node-1"
password: "admin"
server: "big-ip01.internal"
user: "admin"
validate_certs: "no"
delegate_to: localhost

- name: Create node2

bigip_node:
host: "10.10.10.20"
name: "node-2"
password: "admin"
server: "big-ip01.internal"
user: "admin"
validate_certs: "no"
delegate_to: localhost

Note: It is important that the remaining tasks align vertically with the Add a pool task above. If the spacing
doesn’t line up, Ansible will raise an error.

3.3 Add the nodes to the pool

With the pool created and your nodes in place, you now want to add those nodes to the pool. At this point you can
refer to those nodes as pool members.

- name: Add nodes to pool

bigip_pool_member:
description: "webserver-1"
host: "{{ item.host }}"
name: "{{ item.name }}"
password: "admin"
pool: "web"
port: "80"
server: "big-ip01.internal"
user: "admin"
validate_certs: "no"
delegate_to: localhost
with_items:
- host: "10.10.10.10"
name: "node-1"

8 Chapter 3. Run your first BIG-IP playbook

F5 Ansible Documentation, Release 1.0.0

- host: "10.10.10.20"
name: "node-2"

3.4 Add a virtual server

Now that you created your pool and the nodes are members of that pool, you want to create a virtual IP address so that
external requests go to the pool members.
The below example uses 172.16.10.108 as the external address, so you likely need to change it for your own
environment.
To create a virtual server, add the following to your site.yaml:

- name: Create a VIP

bigip_virtual_server:
description: "foo-vip"
destination: "172.16.10.108"
password: "admin"
name: "vip-1"
pool: "web"
port: "80"
server: "big-ip01.internal"
snat: "Automap"
user: "admin"
all_profiles:
- "http"
- "clientssl"
validate_certs: "no"
delegate_to: localhost

3.5 More info

Curious what else is possible with the current modules? Interested in test-driving the modules under development?
Refer to the sidebar for links relevant to your interests.
Want to know the difference between delegate_to and connection:local? See Connection or delegation.

3.4. Add a virtual server 9

F5 Ansible Documentation, Release 1.0.0

10 Chapter 3. Run your first BIG-IP playbook

CHAPTER 4

Connection or delegation

Sometimes you might see examples of F5 Ansible playbooks that use connection: local:

- name: This is my play

hosts: some-host
connection: local

tasks:
...

But other times, you will see delegation used. For example:

- name: This is my play

hosts: some-host

tasks:
- name: This is a task
bigip_command:
commands:
- tmsh list ltm virtual
delegate_to: localhost

See that usage of delegate_to: localhost at the bottom there?

4.1 What’s the difference?

There are three major differences between connection: local and delegate_to: localhost:
• connection: local applies to all hosts
• delegate_to applies to specific hosts
• delegate_to runs your task on one host in the context of another host

11
F5 Ansible Documentation, Release 1.0.0

4.2 Connection: local

First, connection: local applies to all hosts in the playbook. If you find yourself mixing and matching BIG-IP hosts
with things like web servers, it would cause your legitimate ssh connections to fail.
This is because when you specify connection: local, every host is now considered to have 12.0.0.1 as their IP address.
This is likely not what you want.
For example, the following playbook is not what you want.

- name: This is my play

hosts: my-web-server
connection: local

tasks:
- name: Disable pool member for upgrading
bigip_pool_member:
pool: foo
name: "{{ inventory_hostname }}"
state: disabled

- name: Upgrade the webserver

apt:
name: apache2
state: latest

- name: Re-enable pool member after upgrading

bigip_pool_member:
pool: foo
name: "{{ inventory_hostname }}"
state: enabled

The second task is not what you want because it attempts to run the apt module on your local machine. Your
playbook, however, specifically states that it wants to upgrade the remote webserver.

4.3 Delegation

You can remedy this situation with delegate_to. For the most part, you will use this feature when the connection line
is set to ssh (the default).
Delegation allows you to mix and match remote hosts. You continue to use an SSH connection for legitimate purposes,
such as connecting to remove servers, but for the devices that don’t support this option, you delegate their tasks.
For example, this playbook will correct your problem:

- name: This is my play

hosts: my-web-server

tasks:
- name: Disable pool member for upgrading
bigip_pool_member:
pool: foo
name: "{{ inventory_hostname }}"
state: disabled
delegate_to: localhost

12 Chapter 4. Connection or delegation

F5 Ansible Documentation, Release 1.0.0

- name: Upgrade the webserver

apt:
name: apache2
state: latest

- name: Re-enable pool member after upgrading

bigip_pool_member:
pool: foo
name: "{{ inventory_hostname }}"
state: enabled
delegate_to: localhost

The delegate_to parameter delegates the running of the task to some completely different machine.
However, instead of the module having access to that totally different machine’s facts, it instead has the facts of the
inventory item where the delegation happened. This is using the context of the host.

4.4 Summary

Quiz time.
In the above example, even though the first and third tasks are running on the Ansible controller (instead of the remote
webserver), what is the value of the {{ inventory_hostname }} variable?
1. localhost
2. my-web-server
3. something else
If you answered my-web-server then you are correct.
This is context. The task executed on localhost using my-web-server‘s context, and therefore, it is facts.

4.4. Summary 13
F5 Ansible Documentation, Release 1.0.0

14 Chapter 4. Connection or delegation

CHAPTER 5

Install unstable F5 Modules

When you install Ansible, it includes some F5 modules. These modules are “stable.”
Other F5 modules are not yet installed when you install Ansible. These modules are “unstable.”
The tutorials on this site generally use modules that are stable.
You might need to use unstable modules. For example, you may need to test something, or you just can’t wait for a
module to become stable.
You can install these unstable modules on your system in one of a few ways.

5.1 In a relative location (recommended)

Ansible allows you to put modules in a location that is relative to the project you are working on.
To accomplish this, ensure that an ansible.cfg file exists in the directory that you run Ansible from.
Inside the ansible.cfg file, add the following code.

[defaults]
library=./library

This code instructs Ansible to look for modules in a directory called library that is relative to where the ansible.cfg
file exists.
You can take the modules in the f5-ansible repository and put them in that directory.

Note: Specifying a library directory does not override the system location where Ansible searches for modules.
It only tells Ansible to “look here first” when importing a module. Therefore, if a module in the specified library
directory does not exist, Ansible will fall back to the system location and look for the module there.

You can also specify multiple locations by separating them with a colon. For example, if you have two different
directories that have two different sets of modules in them, you might do something like this.

15
F5 Ansible Documentation, Release 1.0.0

[defaults]
library=./library:./unstable

In the example above, when looking for a module named foo.py, Ansible will follow this order:
1. ./library/foo.py
2. ./unstable/foo.py
3. Recursively through /usr/local/lib/PYTHON_VERSION/site-packages/ansible/modules/
Whichever method you choose is up to you.

5.2 In your Ansible install directory

Different systems can put Ansible in different locations. The recommended way to install Ansible (via pip) puts the
modules here:
• /usr/local/lib/PYTHON_VERSION/site-packages/ansible/modules/extras/network/f5/
To install the F5 modules in this repository, you can copy the contents of the library/ directory that F5 provides into
the location mentioned above.
On Mac OS X, you can use the following location for the modules:
• /Library/Frameworks/Python.framework/Versions/[PYTHON_VERSION]/lib/python[PYTHON_VERSION]/site-
packages/ansible/modules/extras/network/f5
For example.

cp library/* /usr/local/lib/PYTHON_VERSION/site-packages/ansible/modules/extras/
˓→network/f5/

This command overwrites all of the modules with the ones in this repository. If you want only one or two modules,
then just copy those. For example:

cp library/bigip_iapp_service.py /usr/local/lib/PYTHON_VERSION/site-packages/ansible/
˓→modules/extras/network/f5/

This example copies only the bigip_iapp_service module.

5.3 Caveats

If you use method #1 and then update your Ansible installation, the update will remove the changes you had made to
your installation.
For this reason, F5 recommends you put modules in your own personal directory and referencing that directory through
your ansible.cfg file.

16 Chapter 5. Install unstable F5 Modules

CHAPTER 6

Filing Issues

Issues, you’ll inevitably run into them. The F5 Module developers are only human (though lauded as superhuman at
times) and therefore we are bound to make mistakes. When we do, it is incumbent upon you, the reader, to call us to
task to fix these issues. Let’s look more at what it takes to file a good, high quality issue, that will allow us to triage
the problem as quickly as possible and get to a solution.

6.1 Be verbose

When you file an issue with the F5 Ansible modules, we will present you with an Issue template. In it we will ask you
questions about your environment, what F5 product and version you are using, etc.
What we’re really interested in here is gathering information so that we can reproduce your environment. We refer
to this reproduction as a “repro”. For us to be successful in repro’ing your issue, we need...no, fanatically demand!...
information about your environment. The more the merrier...to a degree.
Some things we want to know are
• What F5 product?
• What version of that product?
• What Ansible version?
• What python version?
• Whether or not you are using a module in Ansible upstream or one directly from this repo (we have hashes for
this)
• Ansible plays that reproduce the problem
• If this is a feature request, tmsh commands that can be used to meet your needs
• If this is a feature request for a module, an example (in your own YAML) what you think the parameters to the
module would look like.
• Whether you have uploaded a qkview to F5 (we will ask you to contact us offline if you have so we can find
your account)

17
F5 Ansible Documentation, Release 1.0.0

and the list goes on and on. Don’t worry, you don’t need to remember all of the above after reading this, we’ll ask you
again in the Issue template. It all helps, us get a better idea of how your device is configured and how your Ansible
environment is configured.
Some of the things that we do not want, and will never ask for are
• passwords
• license keys
• for you to publicly disclose your company or company contact info. We may as you to contact us “offline”
though.

6.2 Do not comment on closed issues

I need to harp on this because this is something that some people do...and it’s not something you should do.
Two things happen when you comment on closed issues
• We can’t repro is properly in our code-base
• We don’t usually see the notification for it
Let’s take a moment to illustrate why commenting on old issues is a problem for our code base.
You see, when you open an Issue with us, we will create new files in the integration test directory that are named after
your issue.
For example, if you open an issue and it is given the number 1234, then we will create an issue-01234.yaml in our
source tree. This file is related to your issue and no other issues. It is where we, the developers, will work to ensure
that your problem is solved and that we have a historical record of your problem so that all future work we do on the
F5 Ansible modules will continue to work for whatever problem it is that we solved.
This is our means by which we repro your issue, or (in technical mumbo-jumbo) “create a repro” of your issue.
If you do not create a new issue, then this who process is thrown into chaos. We would need to re-visit old stuff and
make changes to previously working code. We would now have a conflict where-by we wouldnt know which issue
this code was meant to fix. We wouldn’t have a clean repro that we could archive as time went on, etc etc etc.
Plain and simple, do not comment on closed issues.

18 Chapter 6. Filing Issues

CHAPTER 7

Module Index

7.1 All Modules

7.1.1 bigip_asm_policy - Manage BIG-IP ASM policies

New in version 2.5.

• Synopsis
• Requirements (on host that executes module)
• Options
• Examples
• Return Values
• Notes
– Status
– Support

Synopsis

• Manage BIG-IP ASM policies.

Requirements (on host that executes module)

• f5-sdk >= 3.0.4

19
F5 Ansible Documentation, Release 1.0.0

Options

Examples

- name: Import and activate ASM policy

bigip_asm_policy:
server: lb.mydomain.com
user: admin
password: secret
name: new_asm_policy
file: /root/asm_policy.xml
active: yes
state: present
delegate_to: localhost

- name: Import ASM policy from template

bigip_asm_policy:
server: lb.mydomain.com
user: admin
password: secret
name: new_sharepoint_policy
template: SharePoint 2007 (http)
state: present
delegate_to: localhost

- name: Create blank ASM policy

bigip_asm_policy:
server: lb.mydomain.com
user: admin
password: secret
name: new_blank_policy
state: present
delegate_to: localhost

- name: Create blank ASM policy and activate

bigip_asm_policy:
server: lb.mydomain.com
user: admin
password: secret
name: new_blank_policy
active: yes
state: present
delegate_to: localhost

- name: Activate ASM policy

bigip_asm_policy:
server: lb.mydomain.com
user: admin
password: secret
name: inactive_policy
active: yes
state: present
delegate_to: localhost

- name: Deactivate ASM policy

bigip_asm_policy:
server: lb.mydomain.com
user: admin

20 Chapter 7. Module Index

F5 Ansible Documentation, Release 1.0.0

password: secret
name: active_policy
state: present
delegate_to: localhost

- name: Import and activate ASM policy in Role

bigip_asm_policy:
server: lb.mydomain.com
user: admin
password: secret
name: new_asm_policy
file: "{{ role_path }}/files/asm_policy.xml"
active: yes
state: present
delegate_to: localhost

- name: Import ASM binary policy

bigip_asm_policy:
server: lb.mydomain.com
user: admin
password: secret
name: new_asm_policy
file: "/root/asm_policy.plc"
active: yes
state: present
delegate_to: localhost

Return Values

Common return values are documented here common_return_values, the following are the fields unique to this module:

Notes

Note:
• For more information on using Ansible to manage F5 Networks devices see https://www.ansible.com/ansible-f5.

Status

This module is flagged as preview which means that it is not guaranteed to have a backwards compatible interface.

Support

This module is community maintained without core committer oversight.

For more information on what this means please read modules_support
For help in developing on modules, should you be so inclined, please read community, dev_guide/developing_test_pr
and dev_guide/developing_modules.

7.1. All Modules 21

F5 Ansible Documentation, Release 1.0.0

7.1.2 bigip_command - Run arbitrary command on F5 devices

New in version 2.4.

• Synopsis
• Requirements (on host that executes module)
• Options
• Examples
• Return Values
• Notes
– Status
– Support

Synopsis

• Sends an arbitrary command to an BIG-IP node and returns the results read from the device. This module
includes an argument that will cause the module to wait for a specific condition before returning or timing out
if the condition is not met.

Requirements (on host that executes module)

• f5-sdk >= 2.2.3

Options

Examples

- name: run show version on remote devices

bigip_command:
commands: show sys version
server: lb.mydomain.com
password: secret
user: admin
validate_certs: no
delegate_to: localhost

- name: run show version and check to see if output contains BIG-IP
bigip_command:
commands: show sys version
wait_for: result[0] contains BIG-IP
server: lb.mydomain.com
password: secret
user: admin
validate_certs: no
delegate_to: localhost

- name: run multiple commands on remote nodes

22 Chapter 7. Module Index

F5 Ansible Documentation, Release 1.0.0

bigip_command:
commands:
- show sys version
- list ltm virtual
server: lb.mydomain.com
password: secret
user: admin
validate_certs: no
delegate_to: localhost

- name: run multiple commands and evaluate the output

bigip_command:
commands:
- show sys version
- list ltm virtual
wait_for:
- result[0] contains BIG-IP
- result[1] contains my-vs
server: lb.mydomain.com
password: secret
user: admin
validate_certs: no
delegate_to: localhost

- name: tmsh prefixes will automatically be handled

bigip_command:
commands:
- show sys version
- tmsh list ltm virtual
server: lb.mydomain.com
password: secret
user: admin
validate_certs: no
delegate_to: localhost

Return Values

Common return values are documented here common_return_values, the following are the fields unique to this module:

Notes

Note:
• Requires the f5-sdk Python package on the host. This is as easy as pip install f5-sdk.
• For more information on using Ansible to manage F5 Networks devices see https://www.ansible.com/ansible-f5.

Status

This module is flagged as preview which means that it is not guaranteed to have a backwards compatible interface.

7.1. All Modules 23

F5 Ansible Documentation, Release 1.0.0

Support

This module is community maintained without core committer oversight.

7.1.3 bigip_config - Manage BIG-IP configuration sections

New in version 2.4.

• Synopsis
• Requirements (on host that executes module)
• Options
• Examples
• Return Values
• Notes
– Status
– Support

Synopsis

• Manages a BIG-IP configuration by allowing TMSH commands that modify running configuration, or merge
SCF formatted files into the running configuration. Additionally, this module is of significant importance be-
cause it allows you to save your running configuration to disk. Since the F5 module only manipulate running
configuration, it is important that you utilize this module to save that running config.

Requirements (on host that executes module)

• f5-sdk >= 2.2.3

Options

Examples

- name: Save the running configuration of the BIG-IP

bigip_config:
save: yes
server: lb.mydomain.com
password: secret
user: admin
validate_certs: no
delegate_to: localhost

24 Chapter 7. Module Index

F5 Ansible Documentation, Release 1.0.0

- name: Reset the BIG-IP configuration, for example, to RMA the device
bigip_config:
reset: yes
save: yes
server: lb.mydomain.com
password: secret
user: admin
validate_certs: no
delegate_to: localhost

- name: Load an SCF configuration

bigip_config:
merge_content: "{{ lookup('file', '/path/to/config.scf') }}"
server: lb.mydomain.com
password: secret
user: admin
validate_certs: no
delegate_to: localhost

Return Values

Common return values are documented here common_return_values, the following are the fields unique to this module:

Notes

Status

This module is flagged as preview which means that it is not guaranteed to have a backwards compatible interface.

Support

This module is community maintained without core committer oversight.

7.1.4 bigip_configsync_action - Perform different actions related to config-sync

New in version 2.4.

7.1. All Modules 25

F5 Ansible Documentation, Release 1.0.0

• Synopsis
• Requirements (on host that executes module)
• Options
• Examples
• Notes
– Status
– Support

Synopsis

• Allows one to run different config-sync actions. These actions allow you to manually sync your configuration
across multiple BIG-IPs when those devices are in an HA pair.

Requirements (on host that executes module)

• f5-sdk >= 2.2.3

Options

Examples

- name: Sync configuration from device to group

bigip_configsync_actions:
device_group: foo-group
sync_device_to_group: yes
server: lb.mydomain.com
user: admin
password: secret
validate_certs: no
delegate_to: localhost

- name: Sync configuration from most recent device to the current host
bigip_configsync_actions:
device_group: foo-group
sync_most_recent_to_device: yes
server: lb.mydomain.com
user: admin
password: secret
validate_certs: no
delegate_to: localhost

- name: Perform an initial sync of a device to a new device group

bigip_configsync_actions:
device_group: new-device-group
sync_device_to_group: yes
server: lb.mydomain.com
user: admin
password: secret

26 Chapter 7. Module Index

F5 Ansible Documentation, Release 1.0.0

validate_certs: no
delegate_to: localhost

Notes

Note:
• Requires the f5-sdk Python package on the host. This is as easy as pip install f5-sdk.
• Requires the objectpath Python package on the host. This is as easy as pip install objectpath.
• For more information on using Ansible to manage F5 Networks devices see https://www.ansible.com/ansible-f5.

Status

This module is flagged as preview which means that it is not guaranteed to have a backwards compatible interface.

Support

This module is community maintained without core committer oversight.

7.1.5 bigip_device_connectivity - Manages device IP configuration settings for HA

on a BIG-IP

New in version 2.4.

• Synopsis
• Requirements (on host that executes module)
• Options
• Examples
• Return Values
• Notes
– Status
– Support

7.1. All Modules 27

F5 Ansible Documentation, Release 1.0.0

Synopsis

• Manages device IP configuration settings for HA on a BIG-IP. Each BIG-IP device has synchronization and
failover connectivity information (IP addresses) that you define as part of HA pairing or clustering. This module
allows you to configure that information.

Requirements (on host that executes module)

• f5-sdk >= 2.2.3

Options

Examples

- name: Configure device connectivity for standard HA pair

bigip_device_connectivity:
config_sync_ip: 10.1.30.1
mirror_primary_address: 10.1.30.1
unicast_failover:
- address: management-ip
- address: 10.1.30.1
server: lb.mydomain.com
user: admin
password: secret
delegate_to: localhost

Return Values

Common return values are documented here common_return_values, the following are the fields unique to this module:

Notes

Note:
• Requires the f5-sdk Python package on the host. This is as easy as pip install f5-sdk.
• This module is primarily used as a component of configuring HA pairs of BIG-IP devices.
• Requires BIG-IP >= 12.1.x.
• For more information on using Ansible to manage F5 Networks devices see https://www.ansible.com/ansible-f5.

Status

This module is flagged as preview which means that it is not guaranteed to have a backwards compatible interface.

28 Chapter 7. Module Index

F5 Ansible Documentation, Release 1.0.0

Support

This module is community maintained without core committer oversight.

7.1.6 bigip_device_dns - Manage BIG-IP device DNS settings

New in version 2.2.

• Synopsis
• Requirements (on host that executes module)
• Options
• Examples
• Return Values
• Notes
– Status
– Support

Synopsis

• Manage BIG-IP device DNS settings

Requirements (on host that executes module)

• f5-sdk

Options

Examples

- name: Set the DNS settings on the BIG-IP

bigip_device_dns:
name_servers:
- 208.67.222.222
- 208.67.220.220
search:
- localdomain
- lab.local
password: secret
server: lb.mydomain.com
user: admin
validate_certs: no
delegate_to: localhost

7.1. All Modules 29

F5 Ansible Documentation, Release 1.0.0

Return Values

Common return values are documented here common_return_values, the following are the fields unique to this module:

Notes

Status

This module is flagged as preview which means that it is not guaranteed to have a backwards compatible interface.

Support

This module is community maintained without core committer oversight.

7.1.7 bigip_device_group - Manage device groups on a BIG-IP

New in version 2.5.

• Synopsis
• Requirements (on host that executes module)
• Options
• Examples
• Return Values
• Notes
– Status
– Support

Synopsis

• Managing device groups allows you to create HA pairs and clusters of BIG-IP devices. Usage of this module
should be done in conjunction with the bigip_configsync_actions to sync configuration across the pair
or cluster if auto-sync is disabled.

30 Chapter 7. Module Index

F5 Ansible Documentation, Release 1.0.0

Requirements (on host that executes module)

• f5-sdk >= 2.2.3

Options

Examples

- name: Create a sync-only device group

bigip_device_group:
name: foo-group
password: secret
server: lb.mydomain.com
state: present
user: admin
delegate_to: localhost

- name: Create a sync-only device group with auto-sync enabled

bigip_device_group:
name: foo-group
auto_sync: yes
password: secret
server: lb.mydomain.com
state: present
user: admin
delegate_to: localhost

Return Values

Common return values are documented here common_return_values, the following are the fields unique to this module:

Notes

Status

This module is flagged as preview which means that it is not guaranteed to have a backwards compatible interface.

Support

This module is community maintained without core committer oversight.

7.1. All Modules 31

F5 Ansible Documentation, Release 1.0.0

For more information on what this means please read modules_support

For help in developing on modules, should you be so inclined, please read community, dev_guide/developing_test_pr
and dev_guide/developing_modules.

7.1.8 bigip_device_group_member - Manages members in a device group

New in version 2.5.

• Synopsis
• Requirements (on host that executes module)
• Options
• Examples
• Notes
– Status
– Support

Synopsis

• Manages members in a device group. Members in a device group can only be added or removed, never updated.
This is because the members are identified by unique name values and changing that name would invalidate the
uniqueness.

Requirements (on host that executes module)

• f5-sdk >= 2.2.3

Options

Examples

- name: Add the current device to the "device_trust_group" device group

bigip_device_group_member:
name: "{{ inventory_hostname }}"
device_group: device_trust_group
password: secret
server: lb.mydomain.com
state: present
user: admin
delegate_to: localhost

- name: Add the hosts in the current scope to "device_trust_group"

bigip_device_group_member:
name: "{{ item }}"
device_group: device_trust_group
password: secret
server: lb.mydomain.com

32 Chapter 7. Module Index

F5 Ansible Documentation, Release 1.0.0

state: present
user: admin
with_items: "{{ hostvars.keys() }}"
run_once: true
delegate_to: localhost

Notes

Status

This module is flagged as preview which means that it is not guaranteed to have a backwards compatible interface.

Support

This module is community maintained without core committer oversight.

7.1.9 bigip_device_ntp - Manage NTP servers on a BIG-IP

New in version 2.2.

• Synopsis
• Requirements (on host that executes module)
• Options
• Examples
• Return Values
• Notes
– Status
– Support

Synopsis

• Manage NTP servers on a BIG-IP.

7.1. All Modules 33

F5 Ansible Documentation, Release 1.0.0

Requirements (on host that executes module)

• f5-sdk

Options

Examples

- name: Set NTP server

bigip_device_ntp:
ntp_servers:
- 192.0.2.23
password: secret
server: lb.mydomain.com
user: admin
validate_certs: no
delegate_to: localhost

- name: Set timezone

bigip_device_ntp:
password: secret
server: lb.mydomain.com
timezone: America/Los_Angeles
user: admin
validate_certs: no
delegate_to: localhost

Return Values

Common return values are documented here common_return_values, the following are the fields unique to this module:

Notes

Status

This module is flagged as preview which means that it is not guaranteed to have a backwards compatible interface.

Support

This module is community maintained without core committer oversight.

34 Chapter 7. Module Index

F5 Ansible Documentation, Release 1.0.0

7.1.10 bigip_device_sshd - Manage the SSHD settings of a BIG-IP

New in version 2.2.

• Synopsis
• Requirements (on host that executes module)
• Options
• Examples
• Return Values
• Notes
– Status
– Support

Synopsis

• Manage the SSHD settings of a BIG-IP.

Requirements (on host that executes module)

• f5-sdk

Options

Examples

- name: Set the banner for the SSHD service from a string
bigip_device_sshd:
banner: enabled
banner_text: banner text goes here
password: secret
server: lb.mydomain.com
user: admin
delegate_to: localhost

- name: Set the banner for the SSHD service from a file
bigip_device_sshd:
banner: enabled
banner_text: "{{ lookup('file', '/path/to/file') }}"
password: secret
server: lb.mydomain.com
user: admin
delegate_to: localhost

- name: Set the SSHD service to run on port 2222

bigip_device_sshd:
password: secret
port: 2222
server: lb.mydomain.com

7.1. All Modules 35

F5 Ansible Documentation, Release 1.0.0

user: admin
delegate_to: localhost

Return Values

Common return values are documented here common_return_values, the following are the fields unique to this module:

Notes

Note:
• Requires the f5-sdk Python package on the host This is as easy as pip install f5-sdk.
• Requires BIG-IP version 12.0.0 or greater
• For more information on using Ansible to manage F5 Networks devices see https://www.ansible.com/ansible-f5.

Status

This module is flagged as preview which means that it is not guaranteed to have a backwards compatible interface.

Support

This module is community maintained without core committer oversight.

7.1.11 bigip_device_trust - Manage the trust relationships between BIG-IPs

New in version 2.5.

• Synopsis
• Requirements (on host that executes module)
• Options
• Examples
• Return Values
• Notes
– Status
– Support

36 Chapter 7. Module Index

F5 Ansible Documentation, Release 1.0.0

Synopsis

• Manage the trust relationships between BIG-IPs. Devices, once peered, cannot be updated. If updating is
needed, the peer must first be removed before it can be re-added to the trust.

Requirements (on host that executes module)

• f5-sdk
• netaddr

Options

Examples

- name: Add trusts for all peer devices to Active device

bigip_device_trust:
server: lb.mydomain.com
user: admin
password: secret
peer_server: "{{ item.ansible_host }}"
peer_hostname: "{{ item.inventory_hostname }}"
peer_user: "{{ item.bigip_username }}"
peer_password: "{{ item.bigip_password }}"
with_items: hostvars
when: inventory_hostname in groups['master']
delegate_to: localhost

Return Values

Common return values are documented here common_return_values, the following are the fields unique to this module:

Notes

Status

This module is flagged as preview which means that it is not guaranteed to have a backwards compatible interface.

Support

This module is community maintained without core committer oversight.

For more information on what this means please read modules_support

7.1. All Modules 37

F5 Ansible Documentation, Release 1.0.0

For help in developing on modules, should you be so inclined, please read community, dev_guide/developing_test_pr
and dev_guide/developing_modules.

7.1.12 bigip_dns_record - Manage DNS resource records on a BIG-IP

New in version 2.2.

• Synopsis
• Requirements (on host that executes module)
• Options
• Examples
• Notes
– Status
– Support

Synopsis

• Manage DNS resource records on a BIG-IP

Requirements (on host that executes module)

• bigsuds
• distutils

Options

Examples

- name: Add an A record to organization.com zone

bigip_dns_record:
user: admin
password: secret
hostname: lb.mydomain.com
type: A
zone: organization.com
state: present
options:
hostname: elliot.organization.com
ip_address: 10.1.1.1
delegate_to: localhost

- name: Add an A record to organization.com zone

local_action:
module: bigip_dns_record
user: admin
password: secret

38 Chapter 7. Module Index

F5 Ansible Documentation, Release 1.0.0

hostname: lb.mydomain.com
type: A
zone: organization.com
state: present
ttl: 10
options:
domain_name: elliot.organization.com
ip_address: 10.1.1.1

Notes

Note:
• Requires the bigsuds Python package on the remote host. This is as easy as pip install bigsuds

Status

This module is flagged as preview which means that it is not guaranteed to have a backwards compatible interface.

Support

This module is community maintained without core committer oversight.

7.1.13 bigip_dns_record_facts - foo

New in version 2.2.

• Synopsis
• Requirements (on host that executes module)
• Options
• Examples
• Notes
– Status
– Support

Synopsis

• foo

7.1. All Modules 39

F5 Ansible Documentation, Release 1.0.0

Requirements (on host that executes module)

• f5-sdk

Options

Examples

Notes

Note:
• Requires the f5-sdk Python package on the remote host. This is as easy as pip install f5-sdk

Status

This module is flagged as preview which means that it is not guaranteed to have a backwards compatible interface.

Support

This module is community maintained without core committer oversight.

7.1.14 bigip_dns_zone - Manages DNS zones on a BIG-IP

New in version 2.2.

• Synopsis
• Requirements (on host that executes module)
• Options
• Examples
• Notes
– Status
– Support

Synopsis

• This module manages DNS zones described in the iControl Management documentation

40 Chapter 7. Module Index

F5 Ansible Documentation, Release 1.0.0

Requirements (on host that executes module)

• bigsuds
• distutils

Options

Examples

- name: Add a view, named "internal", to organization.com zone

module: bigip_view:
username: admin
password: secret
server: lb.mydomain.com
zone_names:
- organization.com
state: present
options:
- domain_name: elliot.organization.com
ip_address: 10.1.1.1

Notes

Note:
• Requires the bigsuds Python package on the remote host. This is as easy as pip install bigsuds
• https://devcentral.f5.com/wiki/iControl.Management__Zone.ashx

Status

This module is flagged as preview which means that it is not guaranteed to have a backwards compatible interface.

Support

This module is community maintained without core committer oversight.

7.1.15 bigip_sys_connection - Run commands on F5 devices via api

New in version 2.2.

• Synopsis

7.1. All Modules 41

F5 Ansible Documentation, Release 1.0.0

• Requirements (on host that executes module)

• Options
• Examples
• Notes
– Status
– Support

Synopsis

• Run commands on F5 devices via api

Requirements (on host that executes module)

• f5-sdk

Options

Examples

- name: Show connections to LTM virtual server

local_action: >
bigip_sys_connection
server={{ f5_ltm_server }}
user={{ f5_ltm_username }}
password={{ f5_ltm_password }}
command="tmsh show sys connection cs-server-addr {{ ip_address }}"

Notes

Note:
• F5 developed module ‘f5-sdk’ required
• Best run as a local_action in your playbook
• Requires administrative privileges for user

Status

This module is flagged as preview which means that it is not guaranteed to have a backwards compatible interface.

42 Chapter 7. Module Index

F5 Ansible Documentation, Release 1.0.0

Support

This module is community maintained without core committer oversight.

7.1.16 _bigip_facts - Collect facts from F5 BIG-IP devices

New in version 1.6.

• DEPRECATED
• Synopsis
• Requirements (on host that executes module)
• Options
• Examples
• Notes

DEPRECATED

Deprecated in 2.5. Use individual facts modules instead.

Synopsis

• Collect facts from F5 BIG-IP devices via iControl SOAP API

Requirements (on host that executes module)

• bigsuds

Options

Examples

- name: Collect BIG-IP facts

bigip_facts:
server: lb.mydomain.com
user: admin
password: secret
include: interface,vlan
delegate_to: localhost

7.1. All Modules 43

F5 Ansible Documentation, Release 1.0.0

Notes

Note:
• Requires BIG-IP software version >= 11.4
• F5 developed module ‘bigsuds’ required (see http://devcentral.f5.com)
• Best run as a local_action in your playbook
• Tested with manager and above account privilege level
• provision facts were added in 2.2
• For more information on using Ansible to manage F5 Networks devices see https://www.ansible.com/ansible-f5.

For help in developing on modules, should you be so inclined, please read community, dev_guide/developing_test_pr
and dev_guide/developing_modules.

7.1.17 bigip_gtm_datacenter - Manage Datacenter configuration in BIG-IP

New in version 2.2.

• Synopsis
• Requirements (on host that executes module)
• Options
• Examples
• Return Values
• Notes
– Status
– Support

Synopsis

• Manage BIG-IP data center configuration. A data center defines the location where the physical network com-
ponents reside, such as the server and link objects that share the same subnet on the network. This module is
able to manipulate the data center definitions in a BIG-IP.

Requirements (on host that executes module)

• f5-sdk

44 Chapter 7. Module Index

F5 Ansible Documentation, Release 1.0.0

Options

Examples

- name: Create data center "New York"

bigip_gtm_datacenter:
server: lb.mydomain.com
user: admin
password: secret
name: New York
location: 222 West 23rd
delegate_to: localhost

Return Values

Common return values are documented here common_return_values, the following are the fields unique to this module:

Notes

Status

This module is flagged as preview which means that it is not guaranteed to have a backwards compatible interface.

Support

This module is community maintained without core committer oversight.

7.1.18 bigip_gtm_facts - Collect facts from F5 BIG-IP GTM devices

New in version 2.3.

• Synopsis
• Requirements (on host that executes module)
• Options
• Examples

7.1. All Modules 45

F5 Ansible Documentation, Release 1.0.0

• Return Values
• Notes
– Status
– Support

Synopsis

• Collect facts from F5 BIG-IP GTM devices.

Requirements (on host that executes module)

• f5-sdk

Options

Examples

- name: Get pool facts

bigip_gtm_facts:
server: lb.mydomain.com
user: admin
password: secret
include: pool
filter: my_pool
delegate_to: localhost

Return Values

Common return values are documented here common_return_values, the following are the fields unique to this module:

Notes

Note:
• Requires the f5-sdk Python package on the host. This is as easy as pip install f5-sdk
• For more information on using Ansible to manage F5 Networks devices see https://www.ansible.com/ansible-f5.

Status

This module is flagged as preview which means that it is not guaranteed to have a backwards compatible interface.

46 Chapter 7. Module Index

F5 Ansible Documentation, Release 1.0.0

Support

This module is community maintained without core committer oversight.

7.1.19 bigip_gtm_pool - Manages F5 BIG-IP GTM pools

New in version 2.4.

• Synopsis
• Requirements (on host that executes module)
• Options
• Examples
• Return Values
• Notes
– Status
– Support

Synopsis

• Manages F5 BIG-IP GTM pools.

Requirements (on host that executes module)

• f5-sdk
• netaddr

Options

Examples

- name: Create a GTM pool

bigip_gtm_pool:
server: lb.mydomain.com
user: admin
password: secret
name: my_pool
delegate_to: localhost

- name: Disable pool

bigip_gtm_pool:
server: lb.mydomain.com

7.1. All Modules 47

F5 Ansible Documentation, Release 1.0.0

user: admin
password: secret
state: disabled
name: my_pool
delegate_to: localhost

Return Values

Common return values are documented here common_return_values, the following are the fields unique to this module:

Notes

Status

This module is flagged as preview which means that it is not guaranteed to have a backwards compatible interface.

Support

This module is community maintained without core committer oversight.

7.1.20 bigip_gtm_server - Manages F5 BIG-IP GTM servers

New in version 2.5.

• Synopsis
• Requirements (on host that executes module)
• Options
• Examples
• Notes
– Status
– Support

48 Chapter 7. Module Index

F5 Ansible Documentation, Release 1.0.0

Synopsis

• Manage BIG-IP server configuration. This module is able to manipulate the server definitions in a BIG-IP.

Requirements (on host that executes module)

• f5-sdk

Options

Examples

- name: Create server "GTM_Server"

bigip_gtm_server:
server: lb.mydomain.com
user: admin
password: secret
name: GTM_Server
datacenter: /Common/New York
product: bigip
link_discovery: disabled
virtual_server_discovery: disabled
devices:
- {'name': 'server_1', 'address': '1.1.1.1'}
- {'name': 'server_2', 'address': '2.2.2.1', 'translation':'192.168.2.1
˓→'}

- {'name': 'server_2', 'address': '2.2.2.2'}

- {'name': 'server_3', 'addresses': [{'address':'3.3.3.1'},{'address':
˓→'3.3.3.2'}]}

- {'name': 'server_4', 'addresses': [{'address':'4.4.4.1','translation

˓→':'192.168.14.1'}, {'address':'4.4.4.2'}]}

delegate_to: localhost

- name: Create server "GTM_Server" with expanded keys

bigip_gtm_server:
server: lb.mydomain.com
user: admin
password: secret
name: GTM_Server
datacenter: /Common/New York
product: bigip
link_discovery: disabled
virtual_server_discovery: disabled
devices:
- name: server_1
address: 1.1.1.1
- name: server_2
address: 2.2.2.1
translation: 192.168.2.1
- name: server_2
address: 2.2.2.2
- name: server_3
addresses:
- address: 3.3.3.1
- address: 3.3.3.2
- name: server_4

7.1. All Modules 49

F5 Ansible Documentation, Release 1.0.0

addresses:
- address: 4.4.4.1
translation: 192.168.14.1
- address: 4.4.4.2
delegate_to: localhost

Notes

Status

This module is flagged as preview which means that it is not guaranteed to have a backwards compatible interface.

Support

This module is community maintained without core committer oversight.

7.1.21 bigip_gtm_virtual_server - Manages F5 BIG-IP GTM virtual servers

New in version 2.2.

• Synopsis
• Requirements (on host that executes module)
• Options
• Examples
• Notes
– Status
– Support

Synopsis

• Manages F5 BIG-IP GTM virtual servers.

50 Chapter 7. Module Index

F5 Ansible Documentation, Release 1.0.0

Requirements (on host that executes module)

• bigsuds

Options

Examples

- name: Enable virtual server

bigip_gtm_virtual_server:
server: lb.mydomain.com
user: admin
password: secret
virtual_server_name: myname
virtual_server_server: myserver
state: enabled
delegate_to: localhost

Notes

Note:
• Requires BIG-IP software version >= 11.4
• F5 developed module ‘bigsuds’ required (see http://devcentral.f5.com)”
• Best run as a local_action in your playbook
• Tested with manager and above account privilege level
• For more information on using Ansible to manage F5 Networks devices see https://www.ansible.com/ansible-f5.

Status

This module is flagged as preview which means that it is not guaranteed to have a backwards compatible interface.

Support

This module is community maintained without core committer oversight.

7.1.22 bigip_gtm_wide_ip - Manages F5 BIG-IP GTM wide ip

New in version 2.0.

7.1. All Modules 51

F5 Ansible Documentation, Release 1.0.0

• Synopsis
• Requirements (on host that executes module)
• Options
• Examples
• Return Values
• Notes
– Status
– Support

Synopsis

• Manages F5 BIG-IP GTM wide ip.

Requirements (on host that executes module)

• f5-sdk

Options

Examples

- name: Set lb method

bigip_gtm_wide_ip:
server: lb.mydomain.com
user: admin
password: secret
lb_method: round-robin
name: my-wide-ip.example.com
delegate_to: localhost

Return Values

Common return values are documented here common_return_values, the following are the fields unique to this module:

Notes

52 Chapter 7. Module Index

F5 Ansible Documentation, Release 1.0.0

Status

This module is flagged as preview which means that it is not guaranteed to have a backwards compatible interface.

Support

This module is community maintained without core committer oversight.

7.1.23 bigip_hostname - Manage the hostname of a BIG-IP

New in version 2.3.

• Synopsis
• Requirements (on host that executes module)
• Options
• Examples
• Return Values
• Notes
– Status
– Support

Synopsis

• Manage the hostname of a BIG-IP.

Requirements (on host that executes module)

• f5-sdk

Options

Examples

- name: Set the hostname of the BIG-IP

bigip_hostname:
hostname: bigip.localhost.localdomain
password: secret
server: lb.mydomain.com
user: admin
delegate_to: localhost

7.1. All Modules 53

F5 Ansible Documentation, Release 1.0.0

Return Values

Common return values are documented here common_return_values, the following are the fields unique to this module:

Notes

Status

This module is flagged as preview which means that it is not guaranteed to have a backwards compatible interface.

Support

This module is community maintained without core committer oversight.

7.1.24 bigip_iapp_service - Manages TCL iApp services on a BIG-IP

New in version 2.4.

• Synopsis
• Requirements (on host that executes module)
• Options
• Examples
• Notes
– Status
– Support

Synopsis

• Manages TCL iApp services on a BIG-IP.

Requirements (on host that executes module)

• f5-sdk

54 Chapter 7. Module Index

F5 Ansible Documentation, Release 1.0.0

Options

Examples

- name: Create HTTP iApp service from iApp template

bigip_iapp_service:
name: foo-service
template: f5.http
parameters: "{{ lookup('file', 'f5.http.parameters.json') }}"
password: secret
server: lb.mydomain.com
state: present
user: admin
delegate_to: localhost

- name: Upgrade foo-service to v1.2.0rc4 of the f5.http template

bigip_iapp_service:
name: foo-service
template: f5.http.v1.2.0rc4
password: secret
server: lb.mydomain.com
state: present
user: admin
delegate_to: localhost

- name: Configure a service using parameters in YAML

- name: Re-configure a service whose underlying iApp was updated in place

bigip_iapp_service:
name: tests
template: web_frontends
password: admin
force: yes
server: "{{ inventory_hostname }}"
server_port: "{{ bigip_port }}"
validate_certs: "{{ validate_certs }}"
state: present
user: admin
parameters:
variables:

7.1. All Modules 55

F5 Ansible Documentation, Release 1.0.0

- name: var__vs_address
value: 1.1.1.1
- name: pm__apache_servers_for_http
value: 2.2.2.1:80
- name: pm__apache_servers_for_https
value: 2.2.2.2:80
delegate_to: localhost

- name: Try to remove the iApp template before the associated Service is
˓→removed

bigip_iapp_template:
name: web_frontends
state: absent
register: result
failed_when:
- not result|success
- "'referenced by one or more applications' not in result.msg"

- name: Configure a service using more complicated parameters

bigip_iapp_service:
name: tests
template: web_frontends
password: admin
server: "{{ inventory_hostname }}"
server_port: "{{ bigip_port }}"
validate_certs: "{{ validate_certs }}"
state: present
user: admin
parameters:
variables:
- name: var__vs_address
value: 1.1.1.1
- name: pm__apache_servers_for_http
value: 2.2.2.1:80
- name: pm__apache_servers_for_https
value: 2.2.2.2:80
lists:
- name: irules__irules
value:
- foo
- bar
tables:
- name: basic__snatpool_members
- name: net__snatpool_members
- name: optimizations__hosts
- name: pool__hosts
columnNames:
- name
rows:
- row:
- internal.company.bar
- name: pool__members
columnNames:
- addr
- port
- connection_limit
rows:
- row:

56 Chapter 7. Module Index

F5 Ansible Documentation, Release 1.0.0

- "none"
- 80
- 0
- name: server_pools__servers
delegate_to: localhost

Notes

Status

This module is flagged as preview which means that it is not guaranteed to have a backwards compatible interface.

Support

This module is community maintained without core committer oversight.

7.1.25 bigip_iapp_template - Manages TCL iApp templates on a BIG-IP

New in version 2.4.

• Synopsis
• Options
• Examples
• Notes
– Status
– Support

Synopsis

• Manages TCL iApp templates on a BIG-IP. This module will allow you to deploy iApp templates to the BIG-
IP and manage their lifecycle. The conventional way to use this module is to import new iApps as needed
or by extracting the contents of the iApp archive that is provided at downloads.f5.com and then importing all
the iApps with this module. This module can also update existing iApps provided that the source of the iApp
changed while the name stayed the same. Note however that this module will not reconfigure any services

7.1. All Modules 57

F5 Ansible Documentation, Release 1.0.0

that may have been created using the bigip_iapp_service module. iApps are normally not updated in
production. Instead, new versions are deployed and then existing services are changed to consume that new
template. As such, the ability to update templates in-place requires the force option to be used.

Options

Examples

- name: Add the iApp contained in template iapp.tmpl

bigip_iapp_template:
content: "{{ lookup('template', 'iapp.tmpl') }}"
password: secret
server: lb.mydomain.com
state: present
user: admin
delegate_to: localhost

- name: Update a template in place

bigip_iapp_template:
content: "{{ lookup('template', 'iapp-new.tmpl') }}"
password: secret
server: lb.mydomain.com
state: present
user: admin
delegate_to: localhost

- name: Update a template in place that has existing services created from
˓→it.

bigip_iapp_template:
content: "{{ lookup('template', 'iapp-new.tmpl') }}"
force: yes
password: secret
server: lb.mydomain.com
state: present
user: admin
delegate_to: localhost

Notes

Status

This module is flagged as preview which means that it is not guaranteed to have a backwards compatible interface.

58 Chapter 7. Module Index

F5 Ansible Documentation, Release 1.0.0

Support

This module is community maintained without core committer oversight.

7.1.26 bigip_iapplx_package - Manages Javascript iApp packages on a BIG-IP

New in version 2.5.

• Synopsis
• Requirements (on host that executes module)
• Options
• Examples
• Notes
– Status
– Support

Synopsis

• Manages Javascript iApp packages on a BIG-IP. This module will allow you to deploy iAppLX packages to the
BIG-IP and manage their lifecycle.

Requirements (on host that executes module)

• f5-sdk >= 2.2.3

• Requires BIG-IP >= 12.1.0
• The ‘rpm’ tool installed on the Ansible controller

Options

Examples

- name: Add an iAppLX package

bigip_iapplx_package:
package: MyApp-0.1.0-0001.noarch.rpm
password: secret
server: lb.mydomain.com
state: present
user: admin
delegate_to: localhost

- name: Add an iAppLX package stored in a role

7.1. All Modules 59

F5 Ansible Documentation, Release 1.0.0

bigip_iapplx_package:
package: "{{ roles_path }}/files/MyApp-0.1.0-0001.noarch.rpm'"
password: secret
server: lb.mydomain.com
state: present
user: admin
delegate_to: localhost

- name: Remove an iAppLX package

bigip_iapplx_package:
package: MyApp-0.1.0-0001.noarch.rpm
password: secret
server: lb.mydomain.com
state: absent
user: admin
delegate_to: localhost

Notes

Note:
• Requires the f5-sdk Python package on the host. This is as easy as pip install f5-sdk.
• Requires the rpm tool be installed on the host. This can be accomplished through different ways on each plat-
form. On Debian based systems with apt; apt-get install rpm. On Mac with brew; brew install
rpm. This command is already present on RedHat based systems.
• Requires BIG-IP < 12.1.0 because the required functionality is missing on versions earlier than that.
• For more information on using Ansible to manage F5 Networks devices see https://www.ansible.com/ansible-f5.

Status

This module is flagged as preview which means that it is not guaranteed to have a backwards compatible interface.

Support

This module is community maintained without core committer oversight.

7.1.27 bigip_irule - Manage iRules across different modules on a BIG-IP

New in version 2.2.

• Synopsis

60 Chapter 7. Module Index

F5 Ansible Documentation, Release 1.0.0

• Requirements (on host that executes module)

• Options
• Examples
• Return Values
• Notes
– Status
– Support

Synopsis

• Manage iRules across different modules on a BIG-IP.

Requirements (on host that executes module)

• f5-sdk

Options

Examples

- name: Add the iRule contained in template irule.tcl to the LTM module
bigip_irule:
content: "{{ lookup('template', 'irule.tcl') }}"
module: ltm
name: MyiRule
password: secret
server: lb.mydomain.com
state: present
user: admin
delegate_to: localhost

- name: Add the iRule contained in static file irule.tcl to the LTM module
bigip_irule:
module: ltm
name: MyiRule
password: secret
server: lb.mydomain.com
src: irule.tcl
state: present
user: admin
delegate_to: localhost

Return Values

Common return values are documented here common_return_values, the following are the fields unique to this module:

7.1. All Modules 61

F5 Ansible Documentation, Release 1.0.0

Notes

Status

This module is flagged as preview which means that it is not guaranteed to have a backwards compatible interface.

Support

This module is community maintained without core committer oversight.

7.1.28 bigip_license - Manage license installation and activation on BIG-IP devices

New in version 2.5.

• Synopsis
• Requirements (on host that executes module)
• Options
• Examples
• Notes
– Status
– Support

Synopsis

• Manage license installation and activation on BIG-IP devices. This module provides two different ways to
license a device. Either via a activation key (which requires a connection back to f5.com) or, with the content of
a license and dossier that you have acquired manually.

Requirements (on host that executes module)

• f5-sdk >= 2.2.3

62 Chapter 7. Module Index

F5 Ansible Documentation, Release 1.0.0

Options

Examples

- name: License BIG-IP using a key

bigip_license:
server: "lb.mydomain.com"
user: "admin"
password: "secret"
key: "XXXXX-XXXXX-XXXXX-XXXXX-XXXXXXX"
delegate_to: localhost

- name: License BIG-IP using a development key

bigip_license:
server: "lb.mydomain.com"
user: "admin"
password: "secret"
key: "XXXXX-XXXXX-XXXXX-XXXXX-XXXXXXX"
license_server: "xxx.f5net.com"
delegate_to: localhost

- name: License BIG-IP using a pre-acquired license

bigip_license:
server: "lb.mydomain.com"
user: "admin"
password: "secret"
license_content: "{{ lookup('file', 'license.lic') }}"
dossier_content: "{{ lookup('file', 'dossier.txt') }}"
delegate_to: localhost

- name: Remove the license from the system

bigip_license:
server: "lb.mydomain.com"
user: "admin"
password: "secret"
state: "absent"
delegate_to: localhost

- name: Update the current license of the BIG-IP

bigip_license:
server: "lb.mydomain.com"
user: "admin"
password: "secret"
key: "XXXXX-XXXXX-XXXXX-XXXXX-XXXXXXX"
state: "latest"
delegate_to: localhost

Notes

Note:
• Requires the f5-sdk Python package on the host. This is as easy as pip install f5-sdk.
• Requires BIG-IP software version >= 12
• For more information on using Ansible to manage F5 Networks devices see https://www.ansible.com/ansible-f5.

7.1. All Modules 63

F5 Ansible Documentation, Release 1.0.0

Status

This module is flagged as preview which means that it is not guaranteed to have a backwards compatible interface.

Support

This module is community maintained without core committer oversight.

7.1.29 bigip_monitor_http - Manages F5 BIG-IP LTM http monitors

New in version 2.5.

• Synopsis
• Requirements (on host that executes module)
• Options
• Examples
• Return Values
• Notes
– Status
– Support

Synopsis

• M
• a
• n
• a
• g
• e
• s
•
• F
• 5
•

64 Chapter 7. Module Index

F5 Ansible Documentation, Release 1.0.0

• B
• I
• G
• –
• I
• P
•
• L
• T
• M
•
• h
• t
• t
• p
•
• m
• o
• n
• i
• t
• o
• r
• s
• .

Requirements (on host that executes module)

• f5-sdk >= 2.2.3

Options

Examples

- name: Create HTTP Monitor

bigip_monitor_http:
state: present
ip: 10.10.10.10
server: lb.mydomain.com
user: admin

7.1. All Modules 65

F5 Ansible Documentation, Release 1.0.0

password: secret
name: my_http_monitor
delegate_to: localhost

- name: Remove HTTP Monitor

bigip_monitor_http:
state: absent
server: lb.mydomain.com
user: admin
password: secret
name: my_http_monitor
delegate_to: localhost

- name: Include a username and password in the HTTP monitor

bigip_monitor_http:
state: absent
server: lb.mydomain.com
user: admin
password: secret
name: my_http_monitor
target_username: monitor_user
target_password: monitor_pass
delegate_to: localhost

Return Values

Common return values are documented here common_return_values, the following are the fields unique to this module:

Notes

Status

This module is flagged as preview which means that it is not guaranteed to have a backwards compatible interface.

Support

This module is community maintained without core committer oversight.

66 Chapter 7. Module Index

F5 Ansible Documentation, Release 1.0.0

7.1.30 _bigip_monitor_http - Manages F5 BIG-IP LTM http monitors

New in version 1.4.

• DEPRECATED
• Synopsis
• Requirements (on host that executes module)
• Options
• Examples
• Notes

DEPRECATED

Deprecated in 2.5. Use bigip_monitor_http instead.

Synopsis

• Manages F5 BIG-IP LTM monitors via iControl SOAP API

Requirements (on host that executes module)

• bigsuds

Options

Examples

- name: BIGIP F5 | Create HTTP Monitor

bigip_monitor_http:
state: present
server: lb.mydomain.com
user: admin
password: secret
name: my_http_monitor
send: http string to send
receive: http string to receive
delegate_to: localhost

- name: BIGIP F5 | Remove HTTP Monitor

bigip_monitor_http:
state: absent
server: lb.mydomain.com
user: admin
password: secret
name: my_http_monitor
delegate_to: localhost

7.1. All Modules 67

F5 Ansible Documentation, Release 1.0.0

Notes

Note:
• Requires BIG-IP software version >= 11
• F5 developed module ‘bigsuds’ required (see http://devcentral.f5.com)
• Best run as a local_action in your playbook
• Monitor API documentation: https://devcentral.f5.com/wiki/iControl.LocalLB__Monitor.ashx
• For more information on using Ansible to manage F5 Networks devices see https://www.ansible.com/ansible-f5.

For help in developing on modules, should you be so inclined, please read community, dev_guide/developing_test_pr
and dev_guide/developing_modules.

7.1.31 bigip_monitor_https - Manages F5 BIG-IP LTM https monitors

New in version 2.5.

• Synopsis
• Requirements (on host that executes module)
• Options
• Examples
• Return Values
• Notes
– Status
– Support

Synopsis

• M
• a
• n
• a
• g
• e
• s
•
• F
• 5
•

68 Chapter 7. Module Index

F5 Ansible Documentation, Release 1.0.0

• B
• I
• G
• –
• I
• P
•
• L
• T
• M
•
• h
• t
• t
• p
• s
•
• m
• o
• n
• i
• t
• o
• r
• s
• .

Requirements (on host that executes module)

• f5-sdk >= 2.2.3

Options

Examples

- name: Create HTTPS Monitor

bigip_monitor_https:
state: present
ip: 10.10.10.10
server: lb.mydomain.com

7.1. All Modules 69

F5 Ansible Documentation, Release 1.0.0

user: admin
password: secret
name: my_http_monitor
delegate_to: localhost

- name: Remove HTTPS Monitor

bigip_monitor_https:
state: absent
server: lb.mydomain.com
user: admin
password: secret
name: my_http_monitor
delegate_to: localhost

Return Values

Common return values are documented here common_return_values, the following are the fields unique to this module:

Notes

Status

This module is flagged as preview which means that it is not guaranteed to have a backwards compatible interface.

Support

This module is community maintained without core committer oversight.

7.1.32 bigip_monitor_snmp_dca - Manages BIG-IP SNMP data collecting agent

(DCA) monitors

New in version 2.5.

• Synopsis
• Requirements (on host that executes module)

70 Chapter 7. Module Index

F5 Ansible Documentation, Release 1.0.0

• Options
• Examples
• Return Values
• Notes
– Status
– Support

Synopsis

• The BIG-IP has an SNMP data collecting agent (DCA) that can query remote SNMP agents of various types,
including the UC Davis agent (UCD) and the Windows 2000 Server agent (WIN2000).

Requirements (on host that executes module)

• f5-sdk >= 2.2.3

Options

Examples

- name: Create SNMP DCS monitor

bigip_monitor_snmp_dca:
state: present
server: lb.mydomain.com
user: admin
password: secret
name: my_monitor
delegate_to: localhost

- name: Remove TCP Echo Monitor

bigip_monitor_snmp_dca:
state: absent
server: lb.mydomain.com
user: admin
password: secret
name: my_monitor
delegate_to: localhost

Return Values

Common return values are documented here common_return_values, the following are the fields unique to this module:

Notes

Note:
• Requires the f5-sdk Python package on the host. This is as easy as pip install f5-sdk.

7.1. All Modules 71

F5 Ansible Documentation, Release 1.0.0

• Requires BIG-IP software version >= 12

• This module does not support the variables option because this option is broken in the REST API and does
not function correctly in tmsh; for example you cannot remove user-defined params. Therefore, there is no way
to automatically configure it.
• For more information on using Ansible to manage F5 Networks devices see https://www.ansible.com/ansible-f5.

Status

This module is flagged as preview which means that it is not guaranteed to have a backwards compatible interface.

Support

This module is community maintained without core committer oversight.

7.1.33 bigip_monitor_tcp - Manages F5 BIG-IP LTM tcp monitors

New in version 1.4.

• Synopsis
• Requirements (on host that executes module)
• Options
• Examples
• Return Values
• Notes
– Status
– Support

Synopsis

• M
• a
• n
• a
• g
• e
• s

72 Chapter 7. Module Index

F5 Ansible Documentation, Release 1.0.0

•
• F
• 5
•
• B
• I
• G
• –
• I
• P
•
• L
• T
• M
•
• t
• c
• p
•
• m
• o
• n
• i
• t
• o
• r
• s
•
• v
• i
• a
•
• i
• C
• o
• n

7.1. All Modules 73

F5 Ansible Documentation, Release 1.0.0

• t
• r
• o
• l
•
• S
• O
• A
• P
•
• A
• P
• I
• .

Requirements (on host that executes module)

• f5-sdk >= 2.2.3

Options

Examples

- name: Create TCP Monitor

bigip_monitor_tcp:
state: present
server: lb.mydomain.com
user: admin
password: secret
name: my_tcp_monitor
type: tcp
send: tcp string to send
receive: tcp string to receive
delegate_to: localhost

- name: Remove TCP Monitor

bigip_monitor_tcp:
state: absent
server: lb.mydomain.com
user: admin
password: secret
name: "my_tcp_monitor
delegate_to: localhost

74 Chapter 7. Module Index

F5 Ansible Documentation, Release 1.0.0

Return Values

Common return values are documented here common_return_values, the following are the fields unique to this module:

Notes

Status

This module is flagged as preview which means that it is not guaranteed to have a backwards compatible interface.

Support

This module is community maintained without core committer oversight.

7.1.34 bigip_monitor_tcp_echo - Manages F5 BIG-IP LTM tcp echo monitors

New in version 2.4.

• Synopsis
• Requirements (on host that executes module)
• Options
• Examples
• Return Values
• Notes
– Status
– Support

Synopsis

• M
• a

7.1. All Modules 75

F5 Ansible Documentation, Release 1.0.0

• n
• a
• g
• e
• s
•
• F
• 5
•
• B
• I
• G
• –
• I
• P
•
• L
• T
• M
•
• t
• c
• p
•
• e
• c
• h
• o
•
• m
• o
• n
• i
• t
• o
• r

76 Chapter 7. Module Index

F5 Ansible Documentation, Release 1.0.0

• s
• .

Requirements (on host that executes module)

• f5-sdk >= 2.2.3

Options

Examples

- name: Create TCP Echo Monitor

bigip_monitor_tcp_echo:
state: present
server: lb.mydomain.com
user: admin
ip: 10.10.10.10
password: secret
name: my_tcp_monitor
delegate_to: localhost

- name: Remove TCP Echo Monitor

bigip_monitor_tcp_echo:
state: absent
server: lb.mydomain.com
user: admin
password: secret
name: my_tcp_monitor
delegate_to: localhost

Return Values

Common return values are documented here common_return_values, the following are the fields unique to this module:

Notes

Status

This module is flagged as preview which means that it is not guaranteed to have a backwards compatible interface.

7.1. All Modules 77

F5 Ansible Documentation, Release 1.0.0

Support

This module is community maintained without core committer oversight.

7.1.35 bigip_monitor_tcp_half_open - Manages F5 BIG-IP LTM tcp half-open moni-

tors

New in version 2.4.

• Synopsis
• Requirements (on host that executes module)
• Options
• Examples
• Return Values
• Notes
– Status
– Support

Synopsis

• M
• a
• n
• a
• g
• e
• s
•
• F
• 5
•
• B
• I
• G
• –

78 Chapter 7. Module Index

F5 Ansible Documentation, Release 1.0.0

• I
• P
•
• L
• T
• M
•
• t
• c
• p
•
• h
• a
• l
• f
• –
• o
• p
• e
• n
•
• m
• o
• n
• i
• t
• o
• r
• s
• .

Requirements (on host that executes module)

• f5-sdk >= 2.2.3

7.1. All Modules 79

F5 Ansible Documentation, Release 1.0.0

Options

Examples

- name: Create TCP Monitor

bigip_monitor_tcp_half_open:
state: present
ip: 10.10.10.10
server: lb.mydomain.com
user: admin
password: secret
name: my_tcp_monitor
delegate_to: localhost

- name: Remove TCP Monitor

bigip_monitor_tcp_half_open:
state: absent
server: lb.mydomain.com
user: admin
password: secret
name: my_tcp_monitor
delegate_to: localhost

- name: Add half-open monitor for all addresses, port 514

bigip_monitor_tcp_half_open:
server: lb.mydomain.com
user: admin
port: 514
password: secret
name: my_tcp_monitor
delegate_to: localhost

Return Values

Common return values are documented here common_return_values, the following are the fields unique to this module:

Notes

Status

This module is flagged as preview which means that it is not guaranteed to have a backwards compatible interface.

80 Chapter 7. Module Index

F5 Ansible Documentation, Release 1.0.0

Support

This module is community maintained without core committer oversight.

7.1.36 _bigip_node - Manages F5 BIG-IP LTM nodes

New in version 1.4.

• DEPRECATED
• Synopsis
• Requirements (on host that executes module)
• Options
• Examples
• Notes

DEPRECATED

Deprecated in 2.5. Use the bigip_node module instead.

Synopsis

• Manages F5 BIG-IP LTM nodes via iControl SOAP API

Requirements (on host that executes module)

• bigsuds

Options

Examples

- name: Add node

bigip_node:
server: lb.mydomain.com
user: admin
password: secret
state: present
partition: Common
host: 10.20.30.40
name: 10.20.30.40
delegate_to: localhost

7.1. All Modules 81

F5 Ansible Documentation, Release 1.0.0

# Note that the BIG-IP automatically names the node using the
# IP address specified in previous play's host parameter.
# Future plays referencing this node no longer use the host
# parameter but instead use the name parameter.
# Alternatively, you could have specified a name with the
# name parameter when state=present.

- name: Add node with a single 'ping' monitor

bigip_node:
server: lb.mydomain.com
user: admin
password: secret
state: present
partition: Common
host: 10.20.30.40
name: mytestserver
monitors:
- /Common/icmp
delegate_to: localhost

- name: Modify node description

bigip_node:
server: lb.mydomain.com
user: admin
password: secret
state: present
partition: Common
name: 10.20.30.40
description: Our best server yet
delegate_to: localhost

- name: Delete node

bigip_node:
server: lb.mydomain.com
user: admin
password: secret
state: absent
partition: Common
name: 10.20.30.40
delegate_to: localhost

# The BIG-IP GUI doesn't map directly to the API calls for "Node ->
# General Properties -> State". The following states map to API monitor
# and session states.
#
# Enabled (all traffic allowed):
# monitor_state=enabled, session_state=enabled
# Disabled (only persistent or active connections allowed):
# monitor_state=enabled, session_state=disabled
# Forced offline (only active connections allowed):
# monitor_state=disabled, session_state=disabled
#
# See https://devcentral.f5.com/questions/icontrol-equivalent-call-for-b-
˓→ node-down

- name: Force node offline

bigip_node:
server: lb.mydomain.com

82 Chapter 7. Module Index

F5 Ansible Documentation, Release 1.0.0

user: admin
password: mysecret
state: present
session_state: disabled
monitor_state: disabled
partition: Common
name: 10.20.30.40
delegate_to: localhost

Notes

Note:
• Requires BIG-IP software version >= 11
• F5 developed module ‘bigsuds’ required (see http://devcentral.f5.com)
• Best run as a local_action in your playbook
• For more information on using Ansible to manage F5 Networks devices see https://www.ansible.com/ansible-f5.

For help in developing on modules, should you be so inclined, please read community, dev_guide/developing_test_pr
and dev_guide/developing_modules.

7.1.37 bigip_node - Manages F5 BIG-IP LTM nodes

New in version 1.4.

• Synopsis
• Requirements (on host that executes module)
• Options
• Examples
• Return Values
• Notes
– Status
– Support

Synopsis

• Manages F5 BIG-IP LTM nodes.

Requirements (on host that executes module)

• f5-sdk >= 3.0.2

7.1. All Modules 83

F5 Ansible Documentation, Release 1.0.0

Options

Examples

- name: Add node

bigip_node:
server: lb.mydomain.com
user: admin
password: secret
state: present
partition: Common
host: 10.20.30.40
name: 10.20.30.40
delegate_to: localhost

- name: Add node with a single 'ping' monitor

bigip_node:
server: lb.mydomain.com
user: admin
password: secret
state: present
partition: Common
host: 10.20.30.40
name: mytestserver
monitors:
- /Common/icmp
delegate_to: localhost

- name: Modify node description

bigip_node:
server: lb.mydomain.com
user: admin
password: secret
state: present
partition: Common
name: 10.20.30.40
description: Our best server yet
delegate_to: localhost

- name: Delete node

bigip_node:
server: lb.mydomain.com
user: admin
password: secret
state: absent
partition: Common
name: 10.20.30.40
delegate_to: localhost

- name: Force node offline

bigip_node:
server: lb.mydomain.com
user: admin
password: secret
state: disabled
partition: Common
name: 10.20.30.40
delegate_to: localhost

84 Chapter 7. Module Index

F5 Ansible Documentation, Release 1.0.0

- name: Add node by their FQDN

bigip_node:
server: lb.mydomain.com
user: admin
password: secret
state: present
partition: Common
fqdn: foo.bar.com
name: 10.20.30.40
delegate_to: localhost

Return Values

Common return values are documented here common_return_values, the following are the fields unique to this module:

Notes

Note:
• Requires the f5-sdk Python package on the host. This is as easy as pip install f5-sdk
• Requires the netaddr Python package on the host. This is as easy as pip install netaddr
• For more information on using Ansible to manage F5 Networks devices see https://www.ansible.com/ansible-f5.

Status

This module is flagged as preview which means that it is not guaranteed to have a backwards compatible interface.

Support

This module is community maintained without core committer oversight.

7.1.38 bigip_partition - Manage BIG-IP partitions

New in version 2.5.

• Synopsis
• Requirements (on host that executes module)
• Options
• Examples

7.1. All Modules 85

F5 Ansible Documentation, Release 1.0.0

• Return Values
• Notes
– Status
– Support

Synopsis

• Manage BIG-IP partitions.

Requirements (on host that executes module)

• f5-sdk >= 2.2.3

Options

Examples

- name: Create partition "foo" using the default route domain

bigip_partition:
name: foo
password: secret
server: lb.mydomain.com
user: admin
delegate_to: localhost

- name: Create partition "bar" using a custom route domain

bigip_partition:
name: bar
route_domain: 3
password: secret
server: lb.mydomain.com
user: admin
delegate_to: localhost

- name: Change route domain of partition "foo"

bigip_partition:
name: foo
route_domain: 8
password: secret
server: lb.mydomain.com
user: admin
delegate_to: localhost

- name: Set a description for partition "foo"

bigip_partition:
name: foo
description: Tenant CompanyA
password: secret
server: lb.mydomain.com
user: admin
delegate_to: localhost

86 Chapter 7. Module Index

F5 Ansible Documentation, Release 1.0.0

- name: Delete the "foo" partition

bigip_partition:
name: foo
password: secret
server: lb.mydomain.com
user: admin
state: absent
delegate_to: localhost

Return Values

Common return values are documented here common_return_values, the following are the fields unique to this module:

Notes

Status

This module is flagged as preview which means that it is not guaranteed to have a backwards compatible interface.

Support

This module is community maintained without core committer oversight.

7.1.39 bigip_policy - Manage general policy configuration on a BIG-IP

New in version 2.5.

• Synopsis
• Requirements (on host that executes module)
• Options
• Examples
• Return Values

7.1. All Modules 87

F5 Ansible Documentation, Release 1.0.0

• Notes
– Status
– Support

Synopsis

• Manages general policy configuration on a BIG-IP. This module is best used in conjunction with the
bigip_policy_rule module. This module can handle general configuration like setting the draft state
of the policy, the description, and things unrelated to the policy rules themselves. It is also the first module that
should be used when creating rules as the bigip_policy_rule module requires a policy parameter.

Requirements (on host that executes module)

• f5-sdk

Options

Examples

- name: Create policy which is immediately published

bigip_policy:
name: Policy-Foo
state: present
delegate_to: localhost

- name: Add a rule to the new policy - Immediately published

bigip_policy_rule:
policy: Policy-Foo
name: ABC
conditions:
- type: http_uri
path_starts_with:
- /ABC
- foo
- bar
path_ends_with:
- baz
actions:
- forward: yes
select: yes
pool: pool-svrs

- name: Add multiple rules to the new policy - Added in the order they are
˓→specified

bigip_policy_rule:
policy: Policy-Foo
name: "{{ item.name }}"
conditions: "{{ item.conditions }}"
actions: "{{ item.actions }}"
with_items:
- name: rule1
actions:

88 Chapter 7. Module Index

F5 Ansible Documentation, Release 1.0.0

- type: forward
pool: pool-svrs
conditions:
- type: http_uri
path_starts_with: /euro
- name: HomePage
actions:
- type: forward
pool: pool-svrs
conditions:
- type: http_uri
path_starts_with: /HomePage/

- name: Create policy specify default rules - Immediately published

bigip_policy:
name: Policy-Bar
state: present
rules:
- rule1
- rule2
- rule3

- name: Create policy specify default rules - Left in a draft

bigip_policy:
name: Policy-Baz
state: draft
rules:
- rule1
- rule2
- rule3

Return Values

Common return values are documented here common_return_values, the following are the fields unique to this module:

Notes

Status

This module is flagged as preview which means that it is not guaranteed to have a backwards compatible interface.

Support

This module is community maintained without core committer oversight.

For more information on what this means please read modules_support

7.1. All Modules 89

F5 Ansible Documentation, Release 1.0.0

For help in developing on modules, should you be so inclined, please read community, dev_guide/developing_test_pr
and dev_guide/developing_modules.

7.1.40 bigip_policy_rule - Manage LTM policy rules on a BIG-IP

New in version 2.5.

• Synopsis
• Requirements (on host that executes module)
• Options
• Examples
• Return Values
• Notes
– Status
– Support

Synopsis

• This module will manage LTM policy rules on a BIG-IP.

Requirements (on host that executes module)

• f5-sdk >= 3.0.0

• BIG-IP >= v12.1.0

Options

Examples

vars:
policy_rules:
- name: rule1
actions:
- type: forward
pool: pool-svrs
conditions:
- type: http_uri
path_starts_with: /euro
- name: rule2
actions:
- type: forward
pool: pool-svrs
conditions:
- type: http_uri
path_starts_with: /HomePage/

90 Chapter 7. Module Index

F5 Ansible Documentation, Release 1.0.0

- name: Create policies

bigip_policy:
name: Policy-Foo
state: present
delegate_to: localhost

- name: Add a rule to the new policy

bigip_policy_rule:
policy: Policy-Foo
name: rule3
conditions:
- type: http_uri
path_begins_with_any: /ABC
actions:
- type: forward
pool: pool-svrs

- name: Add multiple rules to the new policy

bigip_policy_rule:
policy: Policy-Foo
name: "{{ item.name }}"
conditions: "{{ item.conditions }}"
actions: "{{ item.actions }}"
with_items:
- policy_rules

- name: Remove all rules and confitions from the rule

bigip_policy_rule
policy: Policy-Foo
name: "rule1"
conditions:
- type: all_traffic
actions:
- type: ignore

Return Values

Common return values are documented here common_return_values, the following are the fields unique to this module:

Notes

Status

This module is flagged as preview which means that it is not guaranteed to have a backwards compatible interface.

7.1. All Modules 91

F5 Ansible Documentation, Release 1.0.0

Support

This module is community maintained without core committer oversight.

7.1.41 _bigip_pool - Manages F5 BIG-IP LTM pools

• DEPRECATED
• Synopsis
• Requirements (on host that executes module)
• Options
• Examples
• Notes

DEPRECATED

Deprecated in 2.5. Use the bigip_pool module instead.

Synopsis

• Manages F5 BIG-IP LTM pools via iControl SOAP API

Requirements (on host that executes module)

• bigsuds

Options

Examples

- name: Create pool

bigip_pool:
server: lb.mydomain.com
user: admin
password: secret
state: present
name: my-pool
partition: Common
lb_method: least_connection_member
slow_ramp_time: 120
delegate_to: localhost

- name: Modify load balancer method

92 Chapter 7. Module Index

F5 Ansible Documentation, Release 1.0.0

bigip_pool:
server: lb.mydomain.com
user: admin
password: secret
state: present
name: my-pool
partition: Common
lb_method: round_robin
delegate_to: localhost

- name: Add pool member

bigip_pool:
server: lb.mydomain.com
user: admin
password: secret
state: present
name: my-pool
partition: Common
host: "{{ ansible_default_ipv4["address"] }}"
port: 80
delegate_to: localhost

- name: Remove pool member from pool

bigip_pool:
server: lb.mydomain.com
user: admin
password: secret
state: absent
name: my-pool
partition: Common
host: "{{ ansible_default_ipv4["address"] }}"
port: 80
delegate_to: localhost

- name: Delete pool

bigip_pool:
server: lb.mydomain.com
user: admin
password: secret
state: absent
name: my-pool
partition: Common
delegate_to: localhost

Notes

7.1. All Modules 93

F5 Ansible Documentation, Release 1.0.0

For help in developing on modules, should you be so inclined, please read community, dev_guide/developing_test_pr
and dev_guide/developing_modules.

7.1.42 bigip_pool - Manages F5 BIG-IP LTM pools

• Synopsis
• Requirements (on host that executes module)
• Options
• Examples
• Return Values
• Notes
– Status
– Support

Synopsis

• Manages F5 BIG-IP LTM pools via iControl REST API.

Requirements (on host that executes module)

• f5-sdk
• Python >= 2.7

Options

Examples

- name: Create pool

bigip_pool:
server: lb.mydomain.com
user: admin
password: secret
state: present
name: my-pool
partition: Common
lb_method: least_connection_member
slow_ramp_time: 120
delegate_to: localhost

- name: Modify load balancer method

bigip_pool:
server: lb.mydomain.com
user: admin
password: secret
state: present

94 Chapter 7. Module Index

F5 Ansible Documentation, Release 1.0.0

name: my-pool
partition: Common
lb_method: round_robin
delegate_to: localhost

- name: Add pool member

bigip_pool:
server: lb.mydomain.com
user: admin
password: secret
state: present
name: my-pool
partition: Common
host: "{{ ansible_default_ipv4['address'] }}"
port: 80
delegate_to: localhost

- name: Set a single monitor (with enforcement)

bigip_pool:
server: lb.mydomain.com
user: admin
password: secret
state: present
name: my-pool
partition: Common
monitor_type: single
monitors:
- http
delegate_to: localhost

- name: Set a single monitor (without enforcement)

bigip_pool:
server: lb.mydomain.com
user: admin
password: secret
state: present
name: my-pool
partition: Common
monitors:
- http
delegate_to: localhost

- name: Set multiple monitors (all must succeed)

bigip_pool:
server: lb.mydomain.com
user: admin
password: secret
state: present
name: my-pool
partition: Common
monitor_type: and_list
monitors:
- http
- tcp
delegate_to: localhost

- name: Set multiple monitors (at least 1 must succeed)

bigip_pool:

7.1. All Modules 95

F5 Ansible Documentation, Release 1.0.0

server: lb.mydomain.com
user: admin
password: secret
state: present
name: my-pool
partition: Common
monitor_type: m_of_n
quorum: 1
monitors:
- http
- tcp
delegate_to: localhost

- name: Remove pool member from pool

bigip_pool:
server: lb.mydomain.com
user: admin
password: secret
state: absent
name: my-pool
partition: Common
host: "{{ ansible_default_ipv4['address'] }}"
port: 80
delegate_to: localhost

- name: Delete pool

bigip_pool:
server: lb.mydomain.com
user: admin
password: secret
state: absent
name: my-pool
partition: Common
delegate_to: localhost

Return Values

Common return values are documented here common_return_values, the following are the fields unique to this module:

Notes

Note:
• Requires BIG-IP software version >= 12.
• F5 developed module ‘F5-SDK’ required (https://github.com/F5Networks/f5-common-python).
• Best run as a local_action in your playbook.
• For more information on using Ansible to manage F5 Networks devices see https://www.ansible.com/ansible-f5.

96 Chapter 7. Module Index

F5 Ansible Documentation, Release 1.0.0

Status

This module is flagged as preview which means that it is not guaranteed to have a backwards compatible interface.

Support

This module is community maintained without core committer oversight.

7.1.43 _bigip_pool_member - Manages F5 BIG-IP LTM pool members

New in version 1.4.

• DEPRECATED
• Synopsis
• Requirements (on host that executes module)
• Options
• Examples
• Notes

DEPRECATED

Deprecated in 2.5. Use the bigip_pool_member module instead.

Synopsis

• Manages F5 BIG-IP LTM pool members via iControl SOAP API

Requirements (on host that executes module)

• bigsuds

Options

Examples

- name: Add pool member

bigip_pool_member:
server: lb.mydomain.com
user: admin
password: secret
state: present

7.1. All Modules 97

F5 Ansible Documentation, Release 1.0.0

pool: my-pool
partition: Common
host: "{{ ansible_default_ipv4["address"] }}"
port: 80
description: web server
connection_limit: 100
rate_limit: 50
ratio: 2
delegate_to: localhost

- name: Modify pool member ratio and description

bigip_pool_member:
server: lb.mydomain.com
user: admin
password: secret
state: present
pool: my-pool
partition: Common
host: "{{ ansible_default_ipv4["address"] }}"
port: 80
ratio: 1
description: nginx server
delegate_to: localhost

- name: Remove pool member from pool

bigip_pool_member:
server: lb.mydomain.com
user: admin
password: secret
state: absent
pool: my-pool
partition: Common
host: "{{ ansible_default_ipv4["address"] }}"
port: 80
delegate_to: localhost

# The BIG-IP GUI doesn't map directly to the API calls for "Pool ->
# Members -> State". The following states map to API monitor
# and session states.
#
# Enabled (all traffic allowed):
# monitor_state=enabled, session_state=enabled
# Disabled (only persistent or active connections allowed):
# monitor_state=enabled, session_state=disabled
# Forced offline (only active connections allowed):
# monitor_state=disabled, session_state=disabled
#
# See https://devcentral.f5.com/questions/icontrol-equivalent-call-for-b-
˓→ node-down

- name: Force pool member offline

bigip_pool_member:
server: lb.mydomain.com
user: admin
password: secret
state: present
session_state: disabled

98 Chapter 7. Module Index

F5 Ansible Documentation, Release 1.0.0

monitor_state: disabled
pool: my-pool
partition: Common
host: "{{ ansible_default_ipv4["address"] }}"
port: 80
delegate_to: localhost

Notes

Note:
• Requires BIG-IP software version >= 11
• F5 developed module ‘bigsuds’ required (see http://devcentral.f5.com)
• Best run as a local_action in your playbook
• Supersedes bigip_pool for managing pool members
• For more information on using Ansible to manage F5 Networks devices see https://www.ansible.com/ansible-f5.

For help in developing on modules, should you be so inclined, please read community, dev_guide/developing_test_pr
and dev_guide/developing_modules.

7.1.44 bigip_profile_client_ssl - Manages client SSL profiles on a BIG-IP

New in version 2.5.

• Synopsis
• Requirements (on host that executes module)
• Options
• Examples
• Return Values
• Notes
– Status
– Support

Synopsis

• M
• a
• n
• a
• g

7.1. All Modules 99

F5 Ansible Documentation, Release 1.0.0

• e
• s
•
• c
• l
• i
• e
• n
• t
•
• S
• S
• L
•
• p
• r
• o
• f
• i
• l
• e
• s
•
• o
• n
•
• a
•
• B
• I
• G
• –
• I
• P
• .

100 Chapter 7. Module Index

F5 Ansible Documentation, Release 1.0.0

Requirements (on host that executes module)

• f5-sdk >= 2.2.3

Options

Examples

- name: Create client SSL profile

bigip_profile_client_ssl:
state: present
server: lb.mydomain.com
user: admin
password: secret
name: my_profile
delegate_to: localhost

- name: Create client SSL profile with specific ciphers

bigip_profile_client_ssl:
state: present
server: lb.mydomain.com
user: admin
password: secret
name: my_profile
ciphers: "!SSLv3:!SSLv2:ECDHE+AES-GCM+SHA256:ECDHE-RSA-AES128-CBC-SHA"
delegate_to: localhost

- name: Create a client SSL profile with a cert/key/chain setting

bigip_profile_client_ssl:
state: present
server: lb.mydomain.com
user: admin
password: secret
name: my_profile
cert_key_chain:
- cert: bigip_ssl_cert1
key: bigip_ssl_key1
chain: bigip_ssl_cert1
delegate_to: localhost

Return Values

Common return values are documented here common_return_values, the following are the fields unique to this module:

Notes

7.1. All Modules 101

F5 Ansible Documentation, Release 1.0.0

Status

This module is flagged as preview which means that it is not guaranteed to have a backwards compatible interface.

Support

This module is community maintained without core committer oversight.

7.1.45 bigip_provision - Manage BIG-IP module provisioning

New in version 2.4.

• Synopsis
• Requirements (on host that executes module)
• Options
• Examples
• Return Values
• Notes
– Status
– Support

Synopsis

• Manage BIG-IP module provisioning. This module will only provision at the standard levels of Dedicated,
Nominal, and Minimum.

Requirements (on host that executes module)

• f5-sdk >= 2.2.3

Options

Examples

- name: Provision PEM at "nominal" level

bigip_provision:
server: lb.mydomain.com
module: pem
level: nominal
password: secret

102 Chapter 7. Module Index

F5 Ansible Documentation, Release 1.0.0

user: admin
validate_certs: no
delegate_to: localhost

- name: Provision a dedicated SWG. This will unprovision every other module
bigip_provision:
server: lb.mydomain.com
module: swg
password: secret
level: dedicated
user: admin
validate_certs: no
delegate_to: localhost

Return Values

Common return values are documented here common_return_values, the following are the fields unique to this module:

Notes

Status

This module is flagged as preview which means that it is not guaranteed to have a backwards compatible interface.

Support

This module is community maintained without core committer oversight.

7.1.46 bigip_qkview - Manage qkviews on the device

New in version 2.4.

• Synopsis
• Requirements (on host that executes module)
• Options

7.1. All Modules 103

F5 Ansible Documentation, Release 1.0.0

• Examples
• Return Values
• Notes
– Status
– Support

Synopsis

• Manages creating and downloading qkviews from a BIG-IP. Various options can be provided when creating
qkviews. The qkview is important when dealing with F5 support. It may be required that you upload this
qkview to the supported channels during resolution of an SRs that you may have opened.

Requirements (on host that executes module)

• f5-sdk >= 2.2.3

Options

Examples

- name: Fetch a qkview from the remote device

bigip_qkview:
asm_request_log: yes
exclude:
- audit
- secure
dest: /tmp/localhost.localdomain.qkview
delegate_to: localhost

Return Values

Common return values are documented here common_return_values, the following are the fields unique to this module:

Notes

Note:
• Requires the f5-sdk Python package on the host. This is as easy as pip install f5-sdk.
• This module does not include the “max time” or “restrict to blade” options.
• For more information on using Ansible to manage F5 Networks devices see https://www.ansible.com/ansible-f5.

Status

This module is flagged as preview which means that it is not guaranteed to have a backwards compatible interface.

104 Chapter 7. Module Index

F5 Ansible Documentation, Release 1.0.0

Support

This module is community maintained without core committer oversight.

7.1.47 bigip_raw - Run raw commands on F5 devices

New in version 2.5.

• Synopsis
• Requirements (on host that executes module)
• Options
• Examples
• Return Values
• Notes
– Status
– Support

Synopsis

• Sends an arbitrary command to a BIG-IP node and returns the results read from the device. This module
includes an argument that will cause the module to wait for a specific condition before returning or timing out
if the condition is not met. This module is different from the bigip_command module, insofar as it does not
automatically run commands in tmsh.

Requirements (on host that executes module)

• f5-sdk >= 2.2.3

Options

Examples

- name: Run show version on remote devices

bigip_raw:
commands: show sys version
server: lb.mydomain.com
password: "secret
user: admin
validate_certs: no
delegate_to: localhost

7.1. All Modules 105

F5 Ansible Documentation, Release 1.0.0

- name: Run show version and check to see if output contains BIG-IP
bigip_raw:
commands: show sys version
wait_for: result[0] contains BIG-IP
server: lb.mydomain.com
password: secret
user: admin
validate_certs: no
delegate_to: localhost

- name: Run multiple commands on remote nodes

bigip_raw:
commands:
- show sys version
- list ltm virtual
server: lb.mydomain.com
password: secret
user: admin
validate_certs: no
delegate_to: localhost

- name: Run multiple commands and evaluate the output

bigip_raw:
commands:
- show sys version
- list ltm virtual
wait_for:
- result[0] contains BIG-IP
- result[1] contains my-vs
server: lb.mydomain.com
password: secret
user: admin
validate_certs: no
delegate_to: localhost

Return Values

Common return values are documented here common_return_values, the following are the fields unique to this module:

Notes

Status

This module is flagged as preview which means that it is not guaranteed to have a backwards compatible interface.

106 Chapter 7. Module Index

F5 Ansible Documentation, Release 1.0.0

Support

This module is community maintained without core committer oversight.

7.1.48 bigip_remote_syslog - Manipulate remote syslog settings on a BIG-IP

New in version 2.5.

• Synopsis
• Requirements (on host that executes module)
• Options
• Examples
• Return Values
• Notes
– Status
– Support

Synopsis

• Manipulate remote syslog settings on a BIG-IP.

Requirements (on host that executes module)

• f5-sdk >= 2.2.0

• netaddr

Options

Examples

- name: Add a remote syslog server to log to

bigip_remote_syslog:
remote_host: 10.10.10.10
password: secret
server: lb.mydomain.com
user: admin
validate_certs: no
delegate_to: localhost

- name: Add a remote syslog server on a non-standard port to log to

bigip_remote_syslog:

7.1. All Modules 107

F5 Ansible Documentation, Release 1.0.0

remote_host: 10.10.10.10
remote_port: 1234
password: secret
server: lb.mydomain.com
user: admin
validate_certs: no
delegate_to: localhost

Return Values

Common return values are documented here common_return_values, the following are the fields unique to this module:

Notes

Status

This module is flagged as preview which means that it is not guaranteed to have a backwards compatible interface.

Support

This module is community maintained without core committer oversight.

7.1.49 bigip_routedomain - Manage route domains on a BIG-IP

New in version 2.2.

• Synopsis
• Requirements (on host that executes module)
• Options
• Examples
• Return Values
• Notes

108 Chapter 7. Module Index

F5 Ansible Documentation, Release 1.0.0

– Status
– Support

Synopsis

• Manage route domains on a BIG-IP.

Requirements (on host that executes module)

• f5-sdk

Options

Examples

- name: Create a route domain

bigip_routedomain:
name: foo
id: 1234
password: secret
server: lb.mydomain.com
state: present
user: admin
delegate_to: localhost

- name: Set VLANs on the route domain

bigip_routedomain:
name: bar
password: secret
server: lb.mydomain.com
state: present
user: admin
vlans:
- net1
- foo
delegate_to: localhost

Return Values

Common return values are documented here common_return_values, the following are the fields unique to this module:

Notes

7.1. All Modules 109

F5 Ansible Documentation, Release 1.0.0

Status

This module is flagged as preview which means that it is not guaranteed to have a backwards compatible interface.

Support

This module is community maintained without core committer oversight.

7.1.50 bigip_routedomain_facts - Retrieve route domain attributes from a BIG-IP

New in version 2.2.

• Synopsis
• Requirements (on host that executes module)
• Options
• Examples
• Return Values
• Notes
– Status
– Support

Synopsis

• Retrieve route domain attributes from a BIG-IP

Requirements (on host that executes module)

• f5-sdk

Options

Examples

- name: Get the facts for a route domain

bigip_routedomain_facts:
id: 1234
password: secret
server: lb.mydomain.com
user: admin
delegate_to: localhost

110 Chapter 7. Module Index

F5 Ansible Documentation, Release 1.0.0

Return Values

Common return values are documented here common_return_values, the following are the fields unique to this module:

Notes

Note:
• Requires the f5-sdk Python package on the host. This is as easy as pip install f5-sdk

Status

This module is flagged as preview which means that it is not guaranteed to have a backwards compatible interface.

Support

This module is community maintained without core committer oversight.

7.1.51 bigip_selfip - Manage Self-IPs on a BIG-IP system

New in version 2.2.

• Synopsis
• Requirements (on host that executes module)
• Options
• Examples
• Return Values
• Notes
– Status
– Support

Synopsis

• Manage Self-IPs on a BIG-IP system.

7.1. All Modules 111

F5 Ansible Documentation, Release 1.0.0

Requirements (on host that executes module)

• netaddr
• f5-sdk

Options

Examples

- name: Create Self IP

bigip_selfip:
address: 10.10.10.10
name: self1
netmask: 255.255.255.0
password: secret
server: lb.mydomain.com
user: admin
validate_certs: no
vlan: vlan1
delegate_to: localhost

- name: Create Self IP with a Route Domain

bigip_selfip:
server: lb.mydomain.com
user: admin
password: secret
validate_certs: no
name: self1
address: 10.10.10.10
netmask: 255.255.255.0
vlan: vlan1
route_domain: 10
allow_service: default
delegate_to: localhost

- name: Delete Self IP

bigip_selfip:
name: self1
password: secret
server: lb.mydomain.com
state: absent
user: admin
validate_certs: no
delegate_to: localhost

- name: Allow management web UI to be accessed on this Self IP

bigip_selfip:
name: self1
password: secret
server: lb.mydomain.com
state: absent
user: admin
validate_certs: no
allow_service:
- tcp:443
delegate_to: localhost

112 Chapter 7. Module Index

F5 Ansible Documentation, Release 1.0.0

- name: Allow HTTPS and SSH access to this Self IP

bigip_selfip:
name: self1
password: secret
server: lb.mydomain.com
state: absent
user: admin
validate_certs: no
allow_service:
- tcp:443
- tcp:22
delegate_to: localhost

- name: Allow all services access to this Self IP

bigip_selfip:
name: self1
password: secret
server: lb.mydomain.com
state: absent
user: admin
validate_certs: no
allow_service:
- all
delegate_to: localhost

- name: Allow only GRE and IGMP protocols access to this Self IP
bigip_selfip:
name: self1
password: secret
server: lb.mydomain.com
state: absent
user: admin
validate_certs: no
allow_service:
- gre:0
- igmp:0
delegate_to: localhost

- name: Allow all TCP, but no other protocols access to this Self IP
bigip_selfip:
name: self1
password: secret
server: lb.mydomain.com
state: absent
user: admin
validate_certs: no
allow_service:
- tcp:0
delegate_to: localhost

Return Values

Common return values are documented here common_return_values, the following are the fields unique to this module:

7.1. All Modules 113

F5 Ansible Documentation, Release 1.0.0

Notes

Note:
• Requires the f5-sdk Python package on the host. This is as easy as pip install f5-sdk.
• Requires the netaddr Python package on the host.
• For more information on using Ansible to manage F5 Networks devices see https://www.ansible.com/ansible-f5.

Status

This module is flagged as preview which means that it is not guaranteed to have a backwards compatible interface.

Support

This module is community maintained without core committer oversight.

7.1.52 bigip_service - Manage BIG-IP service states

New in version 2.2.

• Synopsis
• Requirements (on host that executes module)
• Options
• Examples
• Notes
– Status
– Support

Synopsis

• Manage BIG-IP service states

Requirements (on host that executes module)

• bigsuds

114 Chapter 7. Module Index

F5 Ansible Documentation, Release 1.0.0

Options

Examples

- name: Restart the BIG-IP sshd service

bigip_service:
server: lb.mydomain.com
name: sshd
user: admin
password: secret
state: restarted
delegate_to: localhost

Notes

Note:
• Requires the bigsuds Python package on the host if using the iControl interface. This is as easy as pip install
bigsuds

Status

This module is flagged as preview which means that it is not guaranteed to have a backwards compatible interface.

Support

This module is community maintained without core committer oversight.

7.1.53 bigip_snat_pool - Manage SNAT pools on a BIG-IP

New in version 2.3.

• Synopsis
• Requirements (on host that executes module)
• Options
• Examples
• Return Values
• Notes
– Status

7.1. All Modules 115

F5 Ansible Documentation, Release 1.0.0

– Support

Synopsis

• Manage SNAT pools on a BIG-IP.

Requirements (on host that executes module)

• f5-sdk

Options

Examples

- name: Add the SNAT pool 'my-snat-pool'

bigip_snat_pool:
server: lb.mydomain.com
user: admin
password: secret
name: my-snat-pool
state: present
members:
- 10.10.10.10
- 20.20.20.20
delegate_to: localhost

- name: Change the SNAT pool's members to a single member

bigip_snat_pool:
server: lb.mydomain.com
user: admin
password: secret
name: my-snat-pool
state: present
member: 30.30.30.30
delegate_to: localhost

- name: Append a new list of members to the existing pool

bigip_snat_pool:
server: lb.mydomain.com
user: admin
password: secret
name: my-snat-pool
state: present
members:
- 10.10.10.10
- 20.20.20.20
delegate_to: localhost

- name: Remove the SNAT pool 'my-snat-pool'

bigip_snat_pool:
server: lb.mydomain.com
user: admin
password: secret

116 Chapter 7. Module Index

F5 Ansible Documentation, Release 1.0.0

name: johnd
state: absent
delegate_to: localhost

Return Values

Common return values are documented here common_return_values, the following are the fields unique to this module:

Notes

Status

This module is flagged as preview which means that it is not guaranteed to have a backwards compatible interface.

Support

This module is community maintained without core committer oversight.

7.1.54 bigip_snmp - Manipulate general SNMP settings on a BIG-IP

New in version 2.4.

• Synopsis
• Requirements (on host that executes module)
• Options
• Examples
• Return Values
• Notes
– Status
– Support

7.1. All Modules 117

F5 Ansible Documentation, Release 1.0.0

Synopsis

• Manipulate general SNMP settings on a BIG-IP.

Requirements (on host that executes module)

• f5-sdk >= 2.2.0

Options

Examples

- name: Set snmp contact

bigip_snmp:
contact: Joe User
password: secret
server: lb.mydomain.com
user: admin
validate_certs: false
delegate_to: localhost

- name: Set snmp location

bigip_snmp:
location: US West 1
password: secret
server: lb.mydomain.com
user: admin
validate_certs: no
delegate_to: localhost

Return Values

Common return values are documented here common_return_values, the following are the fields unique to this module:

Notes

Status

This module is flagged as preview which means that it is not guaranteed to have a backwards compatible interface.

118 Chapter 7. Module Index

F5 Ansible Documentation, Release 1.0.0

Support

This module is community maintained without core committer oversight.

7.1.55 bigip_dns_record_facts - foo

New in version 2.2.

• Synopsis
• Requirements (on host that executes module)
• Options
• Notes
– Status
– Support

Synopsis

• foo

Requirements (on host that executes module)

• f5-sdk

Options

Notes

Note:
• Requires the f5-sdk Python package on the remote host. This is as easy as pip install f5-sdk

Status

This module is flagged as preview which means that it is not guaranteed to have a backwards compatible interface.

7.1. All Modules 119

F5 Ansible Documentation, Release 1.0.0

Support

This module is community maintained without core committer oversight.

7.1.56 bigip_snmp_trap - Manipulate SNMP trap information on a BIG-IP

New in version 2.4.

• Synopsis
• Requirements (on host that executes module)
• Options
• Examples
• Return Values
• Notes
– Status
– Support

Synopsis

• Manipulate SNMP trap information on a BIG-IP.

Requirements (on host that executes module)

• f5-sdk >= 2.2.0

Options

Examples

- name: Create snmp v1 trap

bigip_snmp_trap:
community: general
destination: 1.2.3.4
name: my-trap1
network: management
port: 9000
snmp_version: 1
server: lb.mydomain.com
user: admin
password: secret
delegate_to: localhost

120 Chapter 7. Module Index

F5 Ansible Documentation, Release 1.0.0

- name: Create snmp v2 trap

bigip_snmp_trap:
community: general
destination: 5.6.7.8
name: my-trap2
network: default
port: 7000
snmp_version: 2c
server: lb.mydomain.com
user: admin
password: secret
delegate_to: localhost

Return Values

Common return values are documented here common_return_values, the following are the fields unique to this module:

Notes

Note:
• Requires the f5-sdk Python package on the host. This is as easy as pip install f5-sdk.
• This module only supports version v1 and v2c of SNMP.
• The network option is not supported on versions of BIG-IP < 12.1.0 because the platform did not support that
option until 12.1.0. If used on versions < 12.1.0, it will simply be ignored.
• For more information on using Ansible to manage F5 Networks devices see https://www.ansible.com/ansible-f5.

Status

This module is flagged as preview which means that it is not guaranteed to have a backwards compatible interface.

Support

This module is community maintained without core committer oversight.

7.1.57 bigip_dns_record_facts - foo

New in version 2.2.

• Synopsis

7.1. All Modules 121

F5 Ansible Documentation, Release 1.0.0

• Requirements (on host that executes module)

• Options
• Notes
– Status
– Support

Synopsis

• foo

Requirements (on host that executes module)

• f5-sdk

Options

Notes

Note:
• Requires the f5-sdk Python package on the remote host. This is as easy as pip install f5-sdk

Status

This module is flagged as preview which means that it is not guaranteed to have a backwards compatible interface.

Support

This module is community maintained without core committer oversight.

7.1.58 bigip_software - Manage BIG-IP software versions and hotfixes

New in version 2.4.

• Synopsis
• Requirements (on host that executes module)
• Options

122 Chapter 7. Module Index

F5 Ansible Documentation, Release 1.0.0

• Examples
• Return Values
• Notes
– Status
– Support

Synopsis

• Manage BIG-IP software versions and hotfixes.

Requirements (on host that executes module)

• f5-sdk
• isoparser

Options

Examples

- name: Remove uploaded hotfix

bigip_software:
server: lb.mydomain.com
user: admin
password: secret
hotfix: /root/Hotfix-BIGIP-11.6.0.3.0.412-HF3.iso
state: absent
delegate_to: localhost

- name: Upload hotfix

bigip_software:
server: lb.mydomain.com
user: admin
password: secret
hotfix: /root/Hotfix-BIGIP-11.6.0.3.0.412-HF3.iso
state: present
delegate_to: localhost

- name: Remove uploaded base image

bigip_software:
server: lb.mydomain.com
user: admin
password: secret
software: /root/BIGIP-11.6.0.0.0.401.iso
state: absent
delegate_to: localhost

- name: Upload base image

bigip_software:
server: lb.mydomain.com
user: admin

7.1. All Modules 123

F5 Ansible Documentation, Release 1.0.0

password: secret
software: /root/BIGIP-11.6.0.0.0.401.iso
state: present
delegate_to: localhost

- name: Upload base image and hotfix

bigip_software:
server: lb.mydomain.com
user: admin
password: secret
software: /root/BIGIP-11.6.0.0.0.401.iso
hotfix: /root/Hotfix-BIGIP-11.6.0.3.0.412-HF3.iso
state: present
delegate_to: localhost

- name: Remove uploaded base image and hotfix

bigip_software:
server: lb.mydomain.com
user: admin
password: secret
software: /root/BIGIP-11.6.0.0.0.401.iso
hotfix: /root/Hotfix-BIGIP-11.6.0.3.0.412-HF3.iso
state: absent
delegate_to: localhost

- name: Install (upload, install) base image. Create volume if not exists
bigip_software:
server: lb.mydomain.com
user: admin
password: secret
software: /root/BIGIP-11.6.0.0.0.401.iso
volume: HD1.1
state: installed
delegate_to: localhost

- name: Install (upload, install) base image and hotfix. Create volume if
˓→not exists

bigip_software:
server: lb.mydomain.com
user: admin
password: "secret
software: /root/BIGIP-11.6.0.0.0.401.iso
hotfix: /root/Hotfix-BIGIP-11.6.0.3.0.412-HF3.iso
volume: HD1.1
state: installed
delegate_to: localhost

- name: Activate (upload, install, reboot) base image. Create volume if not
˓→exists

bigip_software:
server: lb.mydomain.com
user: admin
password: secret
software: /root/BIGIP-11.6.0.0.0.401.iso
volume: HD1.1
state: activated
delegate_to: localhost

124 Chapter 7. Module Index

F5 Ansible Documentation, Release 1.0.0

- name: Activate (upload, install, reboot) base image and hotfix. Create
˓→volume if not exists

bigip_software:
server: lb.mydomain.com
user: admin
password: secret
software: /root/BIGIP-11.6.0.0.0.401.iso
hotfix: /root/Hotfix-BIGIP-11.6.0.3.0.412-HF3.iso
volume: HD1.1
state: activated
delegate_to: localhost

- name: Activate (upload, install, reboot) base image and hotfix. Reuse
˓→inactive volume in volumes with prefix.

bigip_software:
server: lb.mydomain.com
user: admin
password: secret
software: /root/BIGIP-11.6.0.0.0.401.iso
hotfix: /root/Hotfix-BIGIP-11.6.0.3.0.412-HF3.iso
reuse_inactive_volume: yes
state: activated
delegate_to: localhost

- name: Activate (download, install, reboot, reuse_inactive_volume) base

˓→image and hotfix

bigip_software:
server: lb.mydomain.com
user: admin
password: secret
hotfix: "http://fake.com/Hotfix-12.1.2.1.0.271-HF1.iso"
hotfix_md5sum: "http://fake.com/Hotfix-12.1.2.1.0.271-HF1.iso.md5"
software: "http://fake.com/BIGIP-12.1.2.0.0.249.iso"
software_md5sum: "http://fake.com/BIGIP-12.1.2.0.0.249.iso.md5"
state: activated
reuse_inactive_volume: True
delegate_to: localhost

- name: Download hotfix image

- name: Remove uploaded hotfix image

bigip_software:
server: lb.mydomain.com
user: admin
password: secret
hotfix: "http://fake.com/Hotfix-12.1.2.1.0.271-HF1.iso"
delegate_to: localhost

- name: Install (download, install) base image

bigip_software:

7.1. All Modules 125

F5 Ansible Documentation, Release 1.0.0

server: lb.mydomain.com
user: admin
password: secret
software: "http://fake.com/BIGIP-12.1.2.0.0.249.iso"
software_md5sum: "http://fake.com/BIGIP-12.1.2.0.0.249.iso.md5"
volume: HD1.1
state: installed
delegate_to: localhost

- name: Install (download, install) base image and hotfix

- name: Download hotfix image (name mismatch)

bigip_software:
server: lb.mydomain.com
user: admin
password: secret
hotfix: "http://fake.com/12.1.2-HF1.iso"
hotfix_md5sum: "http://fake.com/Hotfix-12.1.2HF1.md5"
state: present
delegate_to: localhost

- name: Download software image (name mismatch)

bigip_software:
server: lb.mydomain.com
user: admin
password: secret
software: "http://fake.com/BIGIP-12.1.2.iso"
software_md5sum: "http://fake.com/12.1.2.md5"
state: present
delegate_to: localhost

- name: Activate (download, install, reboot, reuse_inactive_volume) base

˓→image and hotfix

bigip_software:
server: lb.mydomain.com
user: admin
password: secret
hotfix: "http://fake.com/Hotfix-12.1.2.1.0.271-HF1.iso"
hotfix_md5sum: "http://fake.com/Hotfix-12.1.2.1.0.271-HF1.iso.md5"
software: /root/BIGIP-11.6.0.0.0.401.iso
state: activated
reuse_inactive_volume: True
delegate_to: localhost

- name: Activate (download, install, reboot, reuse_inactive_volume) base

˓→image and hotfix

bigip_software:

126 Chapter 7. Module Index

F5 Ansible Documentation, Release 1.0.0

server: lb.mydomain.com
user: admin
password: secret
hotfix: /root/Hotfix-12.1.2.1.0.271-HF1.iso
software: "http://fake.com/BIGIP-12.1.2.0.0.249.iso"
software_md5sum: "http://fake.com/BIGIP-12.1.2.0.0.249.iso.md5"
state: activated
reuse_inactive_volume: True
delegate_to: localhost

Return Values

Common return values are documented here common_return_values, the following are the fields unique to this module:

Notes

Note:
• Requires the f5-sdk Python package on the host. This is as easy as pip install f5-sdk
• Requires the isoparser Python package on the host. This can be installed with pip install isoparser
• Requires the lxml Python package on the host. This can be installed with pip install lxml
• For more information on using Ansible to manage F5 Networks devices see https://www.ansible.com/ansible-f5.

Status

This module is flagged as preview which means that it is not guaranteed to have a backwards compatible interface.

Support

This module is community maintained without core committer oversight.

7.1.59 bigip_software_facts - Collect software facts from BIG-IP devices

New in version 2.5.

• Synopsis
• Requirements (on host that executes module)
• Options
• Examples

7.1. All Modules 127

F5 Ansible Documentation, Release 1.0.0

• Return Values
• Notes
– Status
– Support

Synopsis

• Collect information about installed volumes, existing ISOs for images and hotfixes on the BIG-IP device.

Requirements (on host that executes module)

• f5-sdk

Options

Examples

- name: Gather image facts filter on version

bigip_software_facts:
server: lb.mydomain.com
user: admin
password: secret
include: image
filter: version:12.1.1
delegate_to: localhost

Return Values

Common return values are documented here common_return_values, the following are the fields unique to this module:

Notes

Status

This module is flagged as preview which means that it is not guaranteed to have a backwards compatible interface.

128 Chapter 7. Module Index

F5 Ansible Documentation, Release 1.0.0

Support

This module is community maintained without core committer oversight.

7.1.60 bigip_software_update - Manage the software update settings of a BIG-IP

New in version 2.4.

• Synopsis
• Requirements (on host that executes module)
• Options
• Examples
• Notes
– Status
– Support

Synopsis

• Manage the software update settings of a BIG-IP.

Requirements (on host that executes module)

• f5-sdk >= 2.2.3

Options

Examples

Notes

Note:
• Requires the f5-sdk Python package on the host This is as easy as pip install f5-sdk
• For more information on using Ansible to manage F5 Networks devices see https://www.ansible.com/ansible-f5.

7.1. All Modules 129

F5 Ansible Documentation, Release 1.0.0

Status

This module is flagged as preview which means that it is not guaranteed to have a backwards compatible interface.

Support

This module is community maintained without core committer oversight.

7.1.61 bigip_ssl_certificate - Import/Delete certificates from BIG-IP

New in version 2.2.

• Synopsis
• Requirements (on host that executes module)
• Options
• Examples
• Return Values
• Notes
– Status
– Support

Synopsis

• This module will import/delete SSL certificates on BIG-IP LTM. Certificates can be imported from certificate
and key files on the local disk, in PEM format.

Requirements (on host that executes module)

• f5-sdk >= 3.0.3

• BIG-IP >= v12

Options

Examples

- name: Import PEM Certificate from local disk

bigip_ssl_certificate:
name: certificate-name
server: lb.mydomain.com
user: admin

130 Chapter 7. Module Index

F5 Ansible Documentation, Release 1.0.0

password: secret
state: present
cert_src: /path/to/cert.crt
key_src: /path/to/key.key
delegate_to: localhost

- name: Use a file lookup to import PEM Certificate

bigip_ssl_certificate:
name: certificate-name
server: lb.mydomain.com
user: admin
password: secret
state: present
cert_content: "{{ lookup('file', '/path/to/cert.crt') }}"
key_content: "{{ lookup('file', '/path/to/key.key') }}"
delegate_to: localhost

- name: Use a file lookup to import CA certificate chain

bigip_ssl_certificate:
name: ca-chain-name
server: lb.mydomain.com
user: admin
password: secret
state: present
cert_content: "{{ lookup('file', '/path/to/ca-chain.crt') }}"
delegate_to: localhost

- name: "Delete Certificate"

bigip_ssl_certificate:
name: certificate-name
server: lb.mydomain.com
user: admin
password: secret
state: absent
delegate_to: localhost

Return Values

Common return values are documented here common_return_values, the following are the fields unique to this module:

Notes

Note:
• Requires the f5-sdk Python package on the host. This is as easy as pip install f5-sdk.
• This module does not behave like other modules that you might include in roles where referencing files or
templates first looks in the role’s files or templates directory. To have it behave that way, use the Ansible file or
template lookup (see Examples). The lookups behave as expected in a role context.
• For more information on using Ansible to manage F5 Networks devices see https://www.ansible.com/ansible-f5.

7.1. All Modules 131

F5 Ansible Documentation, Release 1.0.0

Status

This module is flagged as preview which means that it is not guaranteed to have a backwards compatible interface.

Support

This module is community maintained without core committer oversight.

7.1.62 bigip_ssl_key - Import/Delete SSL keys from BIG-IP

New in version 2.5.

• Synopsis
• Requirements (on host that executes module)
• Options
• Examples
• Return Values
• Notes
– Status
– Support

Synopsis

• This module will import/delete SSL keys on a BIG-IP. Keys can be imported from key files on the local disk, in
PEM format.

Requirements (on host that executes module)

• f5-sdk >= 1.5.0

• BIG-IP >= v12

Options

Examples

- name: Use a file lookup to import key

bigip_ssl_key:
name: key-name
server: lb.mydomain.com
user: admin

132 Chapter 7. Module Index

F5 Ansible Documentation, Release 1.0.0

password: secret
state: present
content: "{{ lookup('file', '/path/to/key.key') }}"
delegate_to: localhost

- name: Delete key

bigip_ssl_key:
name: key-name
server: lb.mydomain.com
user: admin
password: secret
state: absent
delegate_to: localhost

Return Values

Common return values are documented here common_return_values, the following are the fields unique to this module:

Notes

Status

This module is flagged as preview which means that it is not guaranteed to have a backwards compatible interface.

Support

This module is community maintained without core committer oversight.

7.1.63 bigip_static_route - Manipulate static routes on a BIG-IP

New in version 2.3.

• Synopsis

7.1. All Modules 133

F5 Ansible Documentation, Release 1.0.0

• Requirements (on host that executes module)

• Options
• Examples
• Return Values
• Notes
– Status
– Support

Synopsis

• Manipulate static routes on a BIG-IP.

Requirements (on host that executes module)

• f5-sdk >= 2.2.3

• netaddr

Options

Examples

- name: Create static route with gateway address

bigip_static_route:
destination: 10.10.10.10
gateway_address: 10.2.2.3
name: test-route
password: secret
server: lb.mydomain.come
user: admin
validate_certs: no
delegate_to: localhost

Return Values

Common return values are documented here common_return_values, the following are the fields unique to this module:

Notes

134 Chapter 7. Module Index

F5 Ansible Documentation, Release 1.0.0

Status

This module is flagged as preview which means that it is not guaranteed to have a backwards compatible interface.

Support

This module is community maintained without core committer oversight.

7.1.64 bigip_sys_db - Manage BIG-IP system database variables

New in version 2.2.

• Synopsis
• Requirements (on host that executes module)
• Options
• Examples
• Return Values
• Notes
– Status
– Support

Synopsis

• Manage BIG-IP system database variables

Requirements (on host that executes module)

• f5-sdk

Options

Examples

- name: Set the boot.quiet DB variable on the BIG-IP

bigip_sys_db:
user: admin
password: secret
server: lb.mydomain.com
key: boot.quiet
value: disable

7.1. All Modules 135

F5 Ansible Documentation, Release 1.0.0

delegate_to: localhost

- name: Disable the initial setup screen

bigip_sys_db:
user: admin
password: secret
server: lb.mydomain.com
key: setup.run
value: false
delegate_to: localhost

- name: Reset the initial setup screen

bigip_sys_db:
user: admin
password: secret
server: lb.mydomain.com
key: setup.run
state: reset
delegate_to: localhost

Return Values

Common return values are documented here common_return_values, the following are the fields unique to this module:

Notes

Note:
• Requires the f5-sdk Python package on the host. This is as easy as pip install f5-sdk.
• Requires BIG-IP version 12.0.0 or greater
• For more information on using Ansible to manage F5 Networks devices see https://www.ansible.com/ansible-f5.

Status

This module is flagged as preview which means that it is not guaranteed to have a backwards compatible interface.

Support

This module is community maintained without core committer oversight.

7.1.65 bigip_sys_global - Manage BIG-IP global settings

New in version 2.3.

136 Chapter 7. Module Index

F5 Ansible Documentation, Release 1.0.0

• Synopsis
• Requirements (on host that executes module)
• Options
• Examples
• Return Values
• Notes
– Status
– Support

Synopsis

• Manage BIG-IP global settings.

Requirements (on host that executes module)

• f5-sdk

Options

Examples

- name: Disable the setup utility

bigip_sys_global:
gui_setup: disabled
password: secret
server: lb.mydomain.com
user: admin
state: present
delegate_to: localhost

Return Values

Common return values are documented here common_return_values, the following are the fields unique to this module:

Notes

7.1. All Modules 137

F5 Ansible Documentation, Release 1.0.0

Status

This module is flagged as preview which means that it is not guaranteed to have a backwards compatible interface.

Support

This module is community maintained without core committer oversight.

7.1.66 bigip_traffic_group - Manages traffic groups on BIG-IP

New in version 2.5.

• Synopsis
• Requirements (on host that executes module)
• Options
• Examples
• Notes
– Status
– Support

Synopsis

• Supports managing traffic groups and their attributes on a BIG-IP.

Requirements (on host that executes module)

• f5-sdk >= 2.2.3

Options

Examples

- name: Create a traffic group

bigip_traffic_group:
name: foo
password: secret
server: lb.mydomain.com
state: present
user: admin
delegate_to: localhost

138 Chapter 7. Module Index

F5 Ansible Documentation, Release 1.0.0

Notes

Status

This module is flagged as preview which means that it is not guaranteed to have a backwards compatible interface.

Support

This module is community maintained without core committer oversight.

7.1.67 bigip_ucs - Manage upload, installation and removal of UCS files

New in version 2.4.

• Synopsis
• Requirements (on host that executes module)
• Options
• Examples
• Notes
– Status
– Support

Synopsis

• Manage upload, installation and removal of UCS files.

Requirements (on host that executes module)

• f5-sdk

7.1. All Modules 139

F5 Ansible Documentation, Release 1.0.0

Options

Examples

- name: Upload UCS

bigip_ucs:
server: lb.mydomain.com
user: admin
password: secret
ucs: /root/bigip.localhost.localdomain.ucs
state: present
delegate_to: localhost

- name: Install (upload, install) UCS.

bigip_ucs:
server: lb.mydomain.com
user: admin
password: secret
ucs: /root/bigip.localhost.localdomain.ucs
state: installed
delegate_to: localhost

- name: Install (upload, install) UCS without installing the license portion
bigip_ucs:
server: lb.mydomain.com
user: admin
password: secret
ucs: /root/bigip.localhost.localdomain.ucs
state: installed
no_license: yes
delegate_to: localhost

- name: Install (upload, install) UCS except the license, and bypassing the
˓→platform check

bigip_ucs:
server: lb.mydomain.com
user: admin
password: secret
ucs: /root/bigip.localhost.localdomain.ucs
state: installed
no_license: yes
no_platform_check: yes
delegate_to: localhost

- name: Install (upload, install) UCS using a passphrase necessary to load

˓→the UCS

bigip_ucs:
server: lb.mydomain.com
user: admin
password: secret
ucs: /root/bigip.localhost.localdomain.ucs
state: installed
passphrase: MyPassphrase1234
delegate_to: localhost

- name: Remove uploaded UCS file

bigip_ucs:
server: lb.mydomain.com

140 Chapter 7. Module Index

F5 Ansible Documentation, Release 1.0.0

user: admin
password: secret
ucs: bigip.localhost.localdomain.ucs
state: absent
delegate_to: localhost

Notes

Note:
• Requires the f5-sdk Python package on the host. This is as easy as pip install f5-sdk.
• Only the most basic checks are performed by this module. Other checks and considerations need to be taken into
account. See the following URL. https://support.f5.com/kb/en-us/solutions/public/11000/300/sol11318.html
• This module does not handle devices with the FIPS 140 HSM
• This module does not handle BIG-IPs systems on the 6400, 6800, 8400, or 8800 hardware platform.
• This module does not verify that the new or replaced SSH keys from the UCS file are synchronized between the
BIG-IP system and the SCCP
• This module does not support the ‘rma’ option
• This module does not support restoring a UCS archive on a BIG-IP 1500, 3400, 4100, 6400, 6800, or 8400
hardware platform other than the system from which the backup was created
• The UCS restore operation restores the full configuration only if the hostname of the target system matches the
hostname on which the UCS archive was created. If the hostname does not match, only the shared configuration
is restored. You can ensure hostnames match by using the bigip_hostname Ansible module in a task before
using this module.
• This module does not support re-licensing a BIG-IP restored from a UCS
• This module does not support restoring encrypted archives on replacement RMA units.
• For more information on using Ansible to manage F5 Networks devices see https://www.ansible.com/ansible-f5.

Status

This module is flagged as preview which means that it is not guaranteed to have a backwards compatible interface.

Support

This module is community maintained without core committer oversight.

7.1. All Modules 141

F5 Ansible Documentation, Release 1.0.0

7.1.68 bigip_ucs_fetch - Fetches a UCS file from remote nodes

New in version 2.4.

• Synopsis
• Requirements (on host that executes module)
• Options
• Examples
• Return Values
• Notes
– Status
– Support

Synopsis

• This module is used for fetching UCS files from remote machines and storing them locally in a file tree, orga-
nized by hostname. Note that this module is written to transfer UCS files that might not be present, so a missing
remote UCS won’t be an error unless fail_on_missing is set to ‘yes’.

Requirements (on host that executes module)

• f5-sdk

Options

Examples

- name: Download a new UCS

bigip_ucs_fetch:
server: lb.mydomain.com
user: admin
password: secret
src: cs_backup.ucs
dest: /tmp/cs_backup.ucs
delegate_to: localhost

Return Values

Common return values are documented here common_return_values, the following are the fields unique to this module:

Notes

Note:

142 Chapter 7. Module Index

F5 Ansible Documentation, Release 1.0.0

• Requires the f5-sdk Python package on the host. This is as easy as pip install f5-sdk.
• BIG-IP provides no way to get a checksum of the UCS files on the system via any interface except, perhaps,
logging in directly to the box (which would not support appliance mode). Therefore, the best this module can
do is check for the existence of the file on disk; no checksumming.

Status

This module is flagged as preview which means that it is not guaranteed to have a backwards compatible interface.

Support

This module is community maintained without core committer oversight.

7.1.69 bigip_user - Manage user accounts and user attributes on a BIG-IP

New in version 2.4.

• Synopsis
• Requirements (on host that executes module)
• Options
• Examples
• Return Values
• Notes
– Status
– Support

Synopsis

• Manage user accounts and user attributes on a BIG-IP. Typically this module operates only on the
REST API users and not the CLI users. There is one exception though and that is if you specify the
username_credential of root. When specifying root, you may only change the password. Your
other parameters will be ignored in this case. Changing the root password is not an idempotent operation.
Therefore, it will change it every time this module attempts to change it.

Requirements (on host that executes module)

• f5-sdk

7.1. All Modules 143

F5 Ansible Documentation, Release 1.0.0

Options

Examples

- name: Add the user 'johnd' as an admin

bigip_user:
server: lb.mydomain.com
user: admin
password: secret
username_credential: johnd
password_credential: password
full_name: John Doe
partition_access: all:admin
update_password: on_create
state: present
delegate_to: localhost

- name: Change the user "johnd's" role and shell

bigip_user:
server: lb.mydomain.com
user: admin
password: secret
username_credential: johnd
partition_access: NewPartition:manager
shell: tmsh
state: present
delegate_to: localhost

- name: Make the user 'johnd' an admin and set to advanced shell
bigip_user:
server: lb.mydomain.com
user: admin
password: secret
name: johnd
partition_access: all:admin
shell: bash
state: present
delegate_to: localhost

- name: Remove the user 'johnd'

bigip_user:
server: lb.mydomain.com
user: admin
password: secret
name: johnd
state: absent
delegate_to: localhost

- name: Update password

bigip_user:
server: lb.mydomain.com
user: admin
password: secret
state: present
username_credential: johnd
password_credential: newsupersecretpassword
delegate_to: localhost

144 Chapter 7. Module Index

F5 Ansible Documentation, Release 1.0.0

# Note that the second time this task runs, it would fail because
# The password has been changed. Therefore, it is recommended that
# you either,
#
# * Put this in its own playbook that you run when you need to
# * Put this task in a `block`
# * Include `ignore_errors` on this task
- name: Change the Admin password
bigip_user:
server: lb.mydomain.com
user: admin
password: secret
state: present
username_credential: admin
password_credential: NewSecretPassword
delegate_to: localhost

- name: Change the root user's password

bigip_user:
server: lb.mydomain.com
user: admin
password: secret
username_credential: root
password_credential: secret
state: present
delegate_to: localhost

Return Values

Common return values are documented here common_return_values, the following are the fields unique to this module:

Notes

Note:
• Requires the f5-sdk Python package on the host. This is as easy as pip install f5-sdk.
• Requires BIG-IP versions >= 12.0.0
• For more information on using Ansible to manage F5 Networks devices see https://www.ansible.com/ansible-f5.

Status

This module is flagged as preview which means that it is not guaranteed to have a backwards compatible interface.

Support

This module is community maintained without core committer oversight.

For more information on what this means please read modules_support

7.1. All Modules 145

F5 Ansible Documentation, Release 1.0.0

For help in developing on modules, should you be so inclined, please read community, dev_guide/developing_test_pr
and dev_guide/developing_modules.

7.1.70 bigip_user_facts - Retrieve user account attributes from a BIG-IP

New in version 2.2.

• Synopsis
• Requirements (on host that executes module)
• Options
• Examples
• Return Values
• Notes
– Status
– Support

Synopsis

• Retrieve user account attributes from a BIG-IP

Requirements (on host that executes module)

• f5-sdk

Options

Examples

- name: Gather facts about user 'johnd'

bigip_user_facts:
name: "johnd"
password: "secret"
server: "lb.mydomain.com"
user: "admin"
validate_certs: "no"
delegate_to: localhost

- name: Display the user facts

debug:
var: bigip

Return Values

Common return values are documented here common_return_values, the following are the fields unique to this module:

146 Chapter 7. Module Index

F5 Ansible Documentation, Release 1.0.0

Notes

Note:
• Requires the f5-sdk Python package on the host. This is as easy as pip install f5-sdk
• Facts are placed in the bigip variable
• For more information on using Ansible to manage F5 Networks devices see https://www.ansible.com/ansible-f5.

Status

This module is flagged as preview which means that it is not guaranteed to have a backwards compatible interface.

Support

This module is community maintained without core committer oversight.

7.1.71 bigip_vcmp_guest - Manages vCMP guests on a BIG-IP

New in version 2.5.

• Synopsis
• Requirements (on host that executes module)
• Options
• Examples
• Return Values
• Notes
– Status
– Support

Synopsis

• Manages vCMP guests on a BIG-IP. This functionality only exists on actual hardware and must be enabled by
provisioning vcmp with the bigip_provision module.

7.1. All Modules 147

F5 Ansible Documentation, Release 1.0.0

Requirements (on host that executes module)

• f5-sdk >= 3.0.3

• netaddr

Options

Examples

- name: Create a vCMP guest

bigip_vcmp_guest:
name: foo
password: secret
server: lb.mydomain.com
state: present
user: admin
mgmt_network: bridge
mgmt_address: 10.20.30.40/24
delegate_to: localhost

- name: Create a vCMP guest with specific VLANs

bigip_vcmp_guest:
name: foo
password: secret
server: lb.mydomain.com
state: present
user: admin
mgmt_network: bridge
mgmt_address: 10.20.30.40/24
vlans:
- vlan1
- vlan2
delegate_to: localhost

- name: Remove vCMP guest and disk

bigip_vcmp_guest:
name: guest1
state: absent
delete_virtual_disk: yes
register: result

Return Values

Common return values are documented here common_return_values, the following are the fields unique to this module:

Notes

Note:
• Requires the f5-sdk Python package on the host. This is as easy as pip install f5-sdk.

148 Chapter 7. Module Index

F5 Ansible Documentation, Release 1.0.0

• This module can take a lot of time to deploy vCMP guests. This is an intrinsic limitation of the vCMP system
because it is booting real VMs on the BIG-IP device. This boot time is very similar in length to the time it takes
to boot VMs on any other virtualization platform; public or private.
• When BIG-IP starts, the VMs are booted sequentially; not in parallel. This means that it is not unusual for a
vCMP host with many guests to take a long time (60+ minutes) to reboot and bring all the guests online. The
BIG-IP chassis will be available before all vCMP guests are online.
• For more information on using Ansible to manage F5 Networks devices see https://www.ansible.com/ansible-f5.

Status

This module is flagged as preview which means that it is not guaranteed to have a backwards compatible interface.

Support

This module is community maintained without core committer oversight.

7.1.72 bigip_view - Manage ZoneRunner Views on a BIG-IP

New in version 2.2.

• Synopsis
• Requirements (on host that executes module)
• Options
• Examples
• Notes
– Status
– Support

Synopsis

• Manage ZoneRunner Views on a BIG-IP. ZoneRunner is a feature of the GTM module. Therefore, this module
should only be used on BIG-IP systems that have the GTM module enabled. The SOAP connection has a number
of known limitations when it comes to updating Views. It is only possible to

Requirements (on host that executes module)

• bigsuds

7.1. All Modules 149

F5 Ansible Documentation, Release 1.0.0

Options

Examples

- name: Create a view foo.local

local_action:
module: "bigip_view"
user: "admin"
password: "admin"
name: "foo.local"

- name: Assign zone "bar" to view "foo.local"

local_action:
module: "bigip_view"
user: "admin"
password: "admin"
name: "foo.local"
zones:
- "bar"

Notes

Note:
• Requires the bigsuds Python package on the remote host. This is as easy as pip install bigsuds

Status

This module is flagged as preview which means that it is not guaranteed to have a backwards compatible interface.

Support

This module is community maintained without core committer oversight.

7.1.73 bigip_virtual_address - Manage LTM virtual addresses on a BIG-IP

New in version 2.4.

• Synopsis
• Requirements (on host that executes module)
• Options
• Examples

150 Chapter 7. Module Index

F5 Ansible Documentation, Release 1.0.0

• Return Values
• Notes
– Status
– Support

Synopsis

• Manage LTM virtual addresses on a BIG-IP.

Requirements (on host that executes module)

• f5-sdk
• netaddr

Options

Examples

- name: Add virtual address

bigip_virtual_address:
server: lb.mydomain.net
user: admin
password: secret
state: present
partition: Common
address: 10.10.10.10
delegate_to: localhost

- name: Enable route advertisement on the virtual address

bigip_virtual_address:
server: lb.mydomain.net
user: admin
password: secret
state: present
address: 10.10.10.10
use_route_advertisement: yes
delegate_to: localhost

Return Values

Common return values are documented here common_return_values, the following are the fields unique to this module:

Notes

Note:
• Requires the f5-sdk Python package on the host. This is as easy as pip install f5-sdk.

7.1. All Modules 151

F5 Ansible Documentation, Release 1.0.0

• Requires the netaddr Python package on the host. This is as easy as pip install netaddr.
• For more information on using Ansible to manage F5 Networks devices see https://www.ansible.com/ansible-f5.

Status

This module is flagged as preview which means that it is not guaranteed to have a backwards compatible interface.

Support

This module is community maintained without core committer oversight.

7.1.74 bigip_virtual_server - Manages F5 BIG-IP LTM virtual servers

New in version 2.1.

• DEPRECATED
• Synopsis
• Requirements (on host that executes module)
• Options
• Examples
• Return Values
• Notes

DEPRECATED

Deprecated in 2.4. Use the bigip_virtual_server module instead.

Synopsis

• Manages F5 BIG-IP LTM virtual servers via iControl SOAP API

Requirements (on host that executes module)

• bigsuds

152 Chapter 7. Module Index

F5 Ansible Documentation, Release 1.0.0

Options

Examples

- name: Add virtual server

bigip_virtual_server:
server: lb.mydomain.net
user: admin
password: secret
state: present
partition: MyPartition
name: myvirtualserver
destination: "{{ ansible_default_ipv4['address'] }}"
port: 443
pool: "{{ mypool }}"
snat: Automap
description: Test Virtual Server
all_profiles:
- http
- clientssl
enabled_vlans:
- /Common/vlan2
delegate_to: localhost

- name: Modify Port of the Virtual Server

bigip_virtual_server:
server: lb.mydomain.net
user: admin
password: secret
state: present
partition: MyPartition
name: myvirtualserver
port: 8080
delegate_to: localhost

- name: Delete virtual server

bigip_virtual_server:
server: lb.mydomain.net
user: admin
password: secret
state: absent
partition: MyPartition
name: myvirtualserver
delegate_to: localhost

Return Values

Common return values are documented here common_return_values, the following are the fields unique to this module:

Notes

Note:
• Requires BIG-IP software version >= 11

7.1. All Modules 153

F5 Ansible Documentation, Release 1.0.0

• F5 developed module ‘bigsuds’ required (see http://devcentral.f5.com)

• Best run as a local_action in your playbook
• For more information on using Ansible to manage F5 Networks devices see https://www.ansible.com/ansible-f5.

For help in developing on modules, should you be so inclined, please read community, dev_guide/developing_test_pr
and dev_guide/developing_modules.

7.1.75 bigip_virtual_server - Manage LTM virtual servers on a BIG-IP

New in version 2.1.

• Synopsis
• Requirements (on host that executes module)
• Options
• Examples
• Return Values
• Notes
– Status
– Support

Synopsis

• Manage LTM virtual servers on a BIG-IP.

Requirements (on host that executes module)

• f5-sdk
• netaddr

Options

Examples

- name: Modify Port of the Virtual Server

bigip_virtual_server:
server: lb.mydomain.net
user: admin
password: secret
state: present
partition: Common
name: my-virtual-server
port: 8080
delegate_to: localhost

154 Chapter 7. Module Index

F5 Ansible Documentation, Release 1.0.0

- name: Delete virtual server

bigip_virtual_server:
server: lb.mydomain.net
user: admin
password: secret
state: absent
partition: Common
name: my-virtual-server
delegate_to: localhost

- name: Add virtual server

bigip_virtual_server:
server: lb.mydomain.net
user: admin
password: secret
state: present
partition: Common
name: my-virtual-server
destination: 10.10.10.10
port: 443
pool: my-pool
snat: Automap
description: Test Virtual Server
profiles:
- http
- fix
- name: clientssl
context: server-side
- name: ilx
context: client-side
policies:
- my-ltm-policy-for-asm
- ltm-uri-policy
- ltm-policy-2
- ltm-policy-3
enabled_vlans:
- /Common/vlan2
delegate_to: localhost

- name: Add FastL4 virtual server

bigip_virtual_server:
destination: 1.1.1.1
name: fastl4_vs
port: 80
profiles:
- fastL4
state: present

Return Values

Common return values are documented here common_return_values, the following are the fields unique to this module:

Notes

7.1. All Modules 155

F5 Ansible Documentation, Release 1.0.0

Note:
• Requires BIG-IP software version >= 11
• Requires the f5-sdk Python package on the host. This is as easy as pip install f5-sdk.
• Requires the netaddr Python package on the host. This is as easy as pip install netaddr.
• For more information on using Ansible to manage F5 Networks devices see https://www.ansible.com/ansible-f5.

Status

This module is flagged as preview which means that it is not guaranteed to have a backwards compatible interface.

Support

This module is community maintained without core committer oversight.

7.1.76 bigip_vlan - Manage VLANs on a BIG-IP system

New in version 2.2.

• Synopsis
• Requirements (on host that executes module)
• Options
• Examples
• Return Values
• Notes
– Status
– Support

Synopsis

• Manage VLANs on a BIG-IP system

Requirements (on host that executes module)

• f5-sdk

156 Chapter 7. Module Index

F5 Ansible Documentation, Release 1.0.0

Options

Examples

- name: Create VLAN

bigip_vlan:
name: "net1"
password: "secret"
server: "lb.mydomain.com"
user: "admin"
validate_certs: "no"
delegate_to: localhost

- name: Add VLAN 2345 as tagged to interface 1.1

bigip_vlan:
tagged_interface: 1.1
name: "net1"
password: "secret"
server: "lb.mydomain.com"
tag: "2345"
user: "admin"
validate_certs: "no"
delegate_to: localhost

- name: Add VLAN 1234 as tagged to interfaces 1.1 and 1.2

bigip_vlan:
tagged_interfaces:
- 1.1
- 1.2
name: "net1"
password: "secret"
server: "lb.mydomain.com"
tag: "1234"
user: "admin"
validate_certs: "no"
delegate_to: localhost

Return Values

Common return values are documented here common_return_values, the following are the fields unique to this module:

Notes

Note:

7.1. All Modules 157

F5 Ansible Documentation, Release 1.0.0

• Requires the f5-sdk Python package on the host. This is as easy as pip install f5-sdk.
• Requires BIG-IP versions >= 12.0.0
• For more information on using Ansible to manage F5 Networks devices see https://www.ansible.com/ansible-f5.

Status

This module is flagged as preview which means that it is not guaranteed to have a backwards compatible interface.

Support

This module is community maintained without core committer oversight.

7.1.77 bigip_wait - Wait for a BIG-IP condition before continuing

New in version 2.5.

• Synopsis
• Requirements (on host that executes module)
• Options
• Examples
• Notes
– Status
– Support

Synopsis

• You can wait for BIG-IP to be “ready”. By “ready”, we mean that BIG-IP is ready to accept configuration.
• This module can take into account situations where the device is in the middle of rebooting due to a configuration
change.

Requirements (on host that executes module)

• f5-sdk >= 2.2.3

158 Chapter 7. Module Index

F5 Ansible Documentation, Release 1.0.0

Options

Examples

- name: Wait for BIG-IP to be ready to take configuration

bigip_wait:
password: secret
server: lb.mydomain.com
user: admin
delegate_to: localhost

- name: Wait a maximum of 300 seconds for BIG-IP to be ready to take

˓→configuration

bigip_wait:
timeout: 300
password: secret
server: lb.mydomain.com
user: admin
delegate_to: localhost

- name: Wait for BIG-IP to be ready, don't start checking for 10 seconds
bigip_wait:
delay: 10
password: secret
server: lb.mydomain.com
user: admin
delegate_to: localhost

Notes

Status

This module is flagged as preview which means that it is not guaranteed to have a backwards compatible interface.

Support

This module is community maintained without core committer oversight.

7.1.78 bigiq_license_pool - Manages license pools of different types

New in version 2.5.

7.1. All Modules 159

F5 Ansible Documentation, Release 1.0.0

• Synopsis
• Requirements (on host that executes module)
• Options
• Examples
• Return Values
• Notes
– Status
– Support

Synopsis

• Manages license pools of different types. The type of the license pool determines the arguments that are provided
to this module. BIG-IQ supports a variety of types of licenses and this module provides a means to manage them.

Requirements (on host that executes module)

• f5-sdk >= 2.2.3

Options

Examples

- name: Create a license pool for a given RegKey license

bigiq_license_pool:
name: "foo"
password: "secret"
server: "lb.mydomain.com"
state: "present"
user: "admin"
delegate_to: localhost

Return Values

Common return values are documented here common_return_values, the following are the fields unique to this module:

Notes

160 Chapter 7. Module Index

F5 Ansible Documentation, Release 1.0.0

Status

This module is flagged as preview which means that it is not guaranteed to have a backwards compatible interface.

Support

This module is community maintained without core committer oversight.

7.1.79 bigiq_license_pool_member - __SHORT_DESCRIPTION__

New in version 2.4.

• Synopsis
• Requirements (on host that executes module)
• Options
• Examples
• Return Values
• Notes
– Status
– Support

Synopsis

• __LONG DESCRIPTION__.

Requirements (on host that executes module)

• f5-sdk >= 2.2.3

Options

Examples

- name: Create a ...

bigiq_license_pool_member:
name: "foo"
password: "secret"
server: "lb.mydomain.com"
state: "present"

7.1. All Modules 161

F5 Ansible Documentation, Release 1.0.0

user: "admin"
delegate_to: localhost

Return Values

Common return values are documented here common_return_values, the following are the fields unique to this module:

Notes

Status

This module is flagged as preview which means that it is not guaranteed to have a backwards compatible interface.

Support

This module is community maintained without core committer oversight.

7.1.80 bigip_partition - Manage BIG-IP partitions

New in version 2.3.

• Synopsis
• Requirements (on host that executes module)
• Options
• Examples
• Notes
– Status
– Support

Synopsis

• Manage BIG-IP partitions

162 Chapter 7. Module Index

F5 Ansible Documentation, Release 1.0.0

Requirements (on host that executes module)

• bigsuds
• requests

Options

Examples

Notes

Note:
• Requires the bigsuds Python package on the host if using the iControl interface. This is as easy as pip install
bigsuds
• For more information on using Ansible to manage F5 Networks devices see https://www.ansible.com/ansible-f5.

Status

This module is flagged as preview which means that it is not guaranteed to have a backwards compatible interface.

Support

This module is community maintained without core committer oversight.

7.1.81 iworkflow_managed_device - Manipulate cloud managed devices in iWork-

flow

New in version 2.4.

• Synopsis
• Requirements (on host that executes module)
• Options
• Examples
• Notes
– Status

7.1. All Modules 163

F5 Ansible Documentation, Release 1.0.0

– Support

Synopsis

• Manipulate cloud managed devices in iWorkflow.

Requirements (on host that executes module)

• f5-sdk >= 1.5.0

• iWorkflow >= 2.1.0

Options

Examples

- name: Discover a BIG-IP device with hostname lb.mydomain.com

iworkflow_device:
device: "lb.mydomain.com
username_credential: "admin"
password_credential: "admin"
password: "secret"
server: "mgmt.mydomain.com"
user: "admin"
delegate_to: localhost

Notes

Status

This module is flagged as preview which means that it is not guaranteed to have a backwards compatible interface.

Support

This module is community maintained without core committer oversight.

164 Chapter 7. Module Index

F5 Ansible Documentation, Release 1.0.0

7.1.82 iworkflow_iapp_template - Manages iApp templates

New in version 2.4.

• Synopsis
• Requirements (on host that executes module)
• Options
• Examples
• Notes
– Status
– Support

Synopsis

• Manages TCL iApp services on a BIG-IP.

Requirements (on host that executes module)

• f5-sdk >= 2.3.0

• iWorkflow >= 2.1.0

Options

Examples

- name: Add AppSvcs Integration to iWorkflow

iworkflow_iapp_template:
device: "my-bigip-1"
template_content: "{{ lookup('file', 'appsvcs_integration_v2.0_001.tmpl
˓→') }}"

password: "secret"
server: "lb.mydomain.com"
state: "present"
user: "admin"
delegate_to: localhost

- name: Remove AppSvcs Integration from iWorkflow

iworkflow_iapp_template:
name: "appsvcs_integration_v2.0_001"
password: "secret"
server: "lb.mydomain.com"
state: "present"
user: "admin"
delegate_to: localhost

7.1. All Modules 165

F5 Ansible Documentation, Release 1.0.0

Notes

Status

This module is flagged as preview which means that it is not guaranteed to have a backwards compatible interface.

Support

This module is community maintained without core committer oversight.

7.1.83 iworkflow_license - Manage license of iWorkflow itself

New in version 2.4.

• Synopsis
• Requirements (on host that executes module)
• Options
• Examples
• Notes
– Status
– Support

Synopsis

• Manage license of iWorkflow itself.

Requirements (on host that executes module)

• f5-sdk >= 2.3.0

• iWorkflow >= 2.1.0

166 Chapter 7. Module Index

F5 Ansible Documentation, Release 1.0.0

Options

Examples

- name: License iWorkflow with a base license

iworkflow_license:
accept_eula: "yes"
base_key: "XXXXX-XXXXX-XXXXX-XXXXX-XXXXXXX"
state: "present"
server: "iwf.mydomain.com"
password: "secret"
user: "admin"
validate_certs: "no"
delegate_to: localhost

- name: License iWorkflow and provide add-on keys

iworkflow_license:
accept_eula: "yes"
base_key: "XXXXX-XXXXX-XXXXX-XXXXX-XXXXXXX"
add_on_keys:
- YYYYY-YYYYY-YYYYY-YYYYY-YYYYYYY
- ZZZZZ-ZZZZZ-ZZZZZ-ZZZZZ-ZZZZZZZ
state: "present"
server: "iwf.mydomain.com"
password: "secret"
user: "admin"
validate_certs: "no"
delegate_to: localhost

Notes

Status

This module is flagged as preview which means that it is not guaranteed to have a backwards compatible interface.

Support

This module is community maintained without core committer oversight.

7.1. All Modules 167

F5 Ansible Documentation, Release 1.0.0

7.1.84 iworkflow_license_pool - Manage license pools in iWorkflow

New in version 2.4.

• Synopsis
• Requirements (on host that executes module)
• Options
• Examples
• Notes
– Status
– Support

Synopsis

• Manage license pools in iWorkflow.

Requirements (on host that executes module)

• f5-sdk >= 2.3.0

• iWorkflow >= 2.1.0

Options

Examples

- name: Create license pool

iworkflow_license_pool:
accept_eula: "yes"
name: "my-lic-pool"
base_key: "XXXXX-XXXXX-XXXXX-XXXXX-XXXXXXX"
state: "present"
server: "iwf.mydomain.com"
password: "secret"
user: "admin"
validate_certs: "no"
delegate_to: localhost

Notes

168 Chapter 7. Module Index

F5 Ansible Documentation, Release 1.0.0

Status

This module is flagged as preview which means that it is not guaranteed to have a backwards compatible interface.

Support

This module is community maintained without core committer oversight.

7.1.85 iworkflow_license_pool_member - Manages members in a license pool

New in version 2.4.

• Synopsis
• Requirements (on host that executes module)
• Options
• Examples
• Notes
– Status
– Support

Synopsis

• Manages members in a license pool. By adding and removing members from a pool, you will implicitly be
licensing and un-licensing them.

Requirements (on host that executes module)

• f5-sdk >= 2.3.0

• iWorkflow >= 2.1.0

Options

Examples

7.1. All Modules 169

F5 Ansible Documentation, Release 1.0.0

Notes

Status

This module is flagged as preview which means that it is not guaranteed to have a backwards compatible interface.

Support

This module is community maintained without core committer oversight.

7.1.86 iworkflow_bigip_connector - Manipulate cloud BIG-IP connectors in iWork-

flow

New in version 2.4.

• Synopsis
• Requirements (on host that executes module)
• Options
• Examples
• Notes
– Status
– Support

Synopsis

• Manipulate cloud BIG-IP connectors in iWorkflow.

Requirements (on host that executes module)

• f5-sdk >= 2.3.0

• iWorkflow >= 2.1.0

170 Chapter 7. Module Index

F5 Ansible Documentation, Release 1.0.0

Options

Examples

- name: Create cloud connector named Private Cloud

iworkflow_bigip_connector:
name: "Private Cloud"
password: "secret"
server: "iwf.mydomain.com"
user: "admin"
delegate_to: localhost

Notes

Status

This module is flagged as preview which means that it is not guaranteed to have a backwards compatible interface.

Support

This module is community maintained without core committer oversight.

7.1.87 iworkflow_local_connector_device - Manipulate cloud local connector de-

vices in iWorkflow

New in version 2.4.

• Synopsis
• Requirements (on host that executes module)
• Options
• Examples
• Notes
– Status
– Support

7.1. All Modules 171

F5 Ansible Documentation, Release 1.0.0

Synopsis

• Manipulate cloud local connector devices in iWorkflow.

Requirements (on host that executes module)

• f5-sdk >= 2.3.0

• iWorkflow >= 2.1.0

Options

Examples

Notes

Status

This module is flagged as preview which means that it is not guaranteed to have a backwards compatible interface.

Support

This module is community maintained without core committer oversight.

7.1.88 iworkflow_local_connector_node - Manages L2/L3 configuration of a BIG-IP

via iWorkflow

New in version 2.3.

• Synopsis
• Requirements (on host that executes module)
• Options
• Examples

172 Chapter 7. Module Index

F5 Ansible Documentation, Release 1.0.0

• Notes
– Status
– Support

Synopsis

• Manages L2/L3 configuration of a BIG-IP via iWorkflow. This module is useful in the event that you have a new
BIG-IP that does not yet have VLANs and Self-IPs configured on it. You can use this module on a discovered,
managed, device to configure those settings via iWorkflow. You do not need touse this module if you have an
existing BIG-IP that has its L2/L3 configuration already complete. In that cae, it is sufficient to just use the
iworkflow_managed_device module and iWorkflow will automatically discover the node information
for you.

Requirements (on host that executes module)

• f5-sdk >= 2.2.0

• iWorkflow >= 2.1.0

Options

Examples

- name: Create node from managed device

iworkflow_local_connector_node:
device: "10.144.128.137"
password_credential: "secret"
username_credential: "admin"
state: "present"
connector: "Private OpenStack"
hostname: "lb1.example.com"
interfaces:
- local_address: "10.144.128.137"
subnet_address: "10.144.128/24"
- local_address: "10.2.0.81"
subnet_address: "10.2.0.0/24"
name: "internal"
server: "iwf.mydomain.com"
password: "secret"
user: "admin"
validate_certs: "no"
delegate_to: localhost

- name: Create node from managed device in Azure

iworkflow_local_connector_node:
device: "10.144.128.137"
password_credential: "secret"
username_credential: "admin"
device_root_password: "default"
state: "present"
connector: "Public Azure West US"
hostname: "lb1.example.com"

7.1. All Modules 173

F5 Ansible Documentation, Release 1.0.0

interfaces:
- local_address: "10.0.2.12"
subnet_address: "10.0.2.0/24"
virtual_address: "10.144.128.137"
- local_address: "10.2.0.81"
subnet_address: "10.2.0.0/24"
name: "external"
server: "iwf.mydomain.com"
password: "secret"
user: "admin"
validate_certs: "no"
delegate_to: localhost

Notes

Note:
• Requires the f5-sdk Python package on the host. This is as easy as pip install f5-sdk.
• Requires the netaddr Python package on the host. This is as easy as pip install netaddr.
• This module does not support updating of existing nodes that were created with a
cli_password_credential. The onboarding process will change your device’s
cli_username_credential password, which will prevent you from using this module (without
knowing the password) a second time.
• For more information on using Ansible to manage F5 Networks devices see https://www.ansible.com/ansible-f5.

Status

This module is flagged as preview which means that it is not guaranteed to have a backwards compatible interface.

Support

This module is community maintained without core committer oversight.

7.1.89 iworkflow_service - Manages L4/L7 Services on iWorkflow

New in version 2.4.

• Synopsis
• Requirements (on host that executes module)
• Options

174 Chapter 7. Module Index

F5 Ansible Documentation, Release 1.0.0

• Examples
• Notes
– Status
– Support

Synopsis

• Manages L4/L7 Service on iWorkflow. Services can only be created and otherwise managed by tenants on
iWorkflow. Since all of the F5 modules assume the use of the administrator account, the user of this module will
need to include the tenant option if they want to use this module with the admin account.

Requirements (on host that executes module)

• f5-sdk >= 2.3.0

• iWorkflow >= 2.1.0

Options

Examples

Notes

Note:
• Requires the f5-sdk Python package on the remote host. This is as easy as pip install f5-sdk.
• L4/L7 Services cannot be updated once they have been created. Instead, you must first delete the service and
then re-create it.

Status

This module is flagged as preview which means that it is not guaranteed to have a backwards compatible interface.

Support

This module is community maintained without core committer oversight.

7.1. All Modules 175

F5 Ansible Documentation, Release 1.0.0

7.1.90 iworkflow_service_template - Manages Service Templates on iWorkflow

New in version 2.4.

• Synopsis
• Requirements (on host that executes module)
• Options
• Examples
• Notes
– Status
– Support

Synopsis

• Manages Service Templates on iWorkflow. Service templates are created by the iWorkflow administrator and
are consumed by iWorkflow tenants in the form of L4/L7 services. The Service Template can be configured to
allow tenants to change certain values of the template such as the IP address of a VIP, or the port that a Virtual
Server listens on.

Requirements (on host that executes module)

• f5-sdk >= 2.3.0

• iWorkflow >= 2.1.0

Options

Examples

Notes

Note:
• Requires the f5-sdk Python package on the remote host. This is as easy as pip install f5-sdk
• Requires the deepdiff Python package on the Ansible controller host. This is as easy as pip install deepdiff.

Status

This module is flagged as preview which means that it is not guaranteed to have a backwards compatible interface.

176 Chapter 7. Module Index

F5 Ansible Documentation, Release 1.0.0

Support

This module is community maintained without core committer oversight.

7.1.91 iworkflow_system_setup - Manage system setup related configuration on

iWorkflow

New in version 2.4.

• Synopsis
• Requirements (on host that executes module)
• Options
• Examples
• Notes
– Status
– Support

Synopsis

• Manage system setup related configuration on iWorkflow.

Requirements (on host that executes module)

• f5-sdk >= 2.2.2

• iWorkflow >= 2.1.0

Options

Examples

- name: Disable iWorkflow setup screen and set accounts as unchanged

iworkflow_system_setup:
is_admin_password_changed: "no"
is_root_password_changed: "no"
is_system_setup: "yes"
password: "secret"
server: "iwf.mydomain.com"
user: "admin"
delegate_to: localhost

7.1. All Modules 177

F5 Ansible Documentation, Release 1.0.0

Notes

Note:
• Requires the f5-sdk Python package on the host. This is as easy as pip install f5-sdk.
• Required the netaddr Python package on the host. This is as easy as pip install netaddr.
• For more information on using Ansible to manage F5 Networks devices see https://www.ansible.com/ansible-f5.

Status

This module is flagged as preview which means that it is not guaranteed to have a backwards compatible interface.

Support

This module is community maintained without core committer oversight.

7.1.92 iworkflow_tenant - Manage tenants in iWorkflow

New in version 2.4.

• Synopsis
• Requirements (on host that executes module)
• Options
• Examples
• Notes
– Status
– Support

Synopsis

• Manage tenants in iWorkflow.

Requirements (on host that executes module)

• f5-sdk >= 2.3.0

• iWorkflow >= 2.1.0

178 Chapter 7. Module Index

F5 Ansible Documentation, Release 1.0.0

Options

Examples

Notes

Note:
• Requires the f5-sdk Python package on the host. This is as easy as pip install f5-sdk.
• Tenants are not useful unless you associate them with a connector using the
iworkflow_tenant_connector module.
• For more information on using Ansible to manage F5 Networks devices see https://www.ansible.com/ansible-f5.

Status

This module is flagged as preview which means that it is not guaranteed to have a backwards compatible interface.

Support

This module is community maintained without core committer oversight.

7.1.93 iworkflow_tenant_connector - Manage connectors associated with tenants

in iWorkflow

New in version 2.4.

• Synopsis
• Requirements (on host that executes module)
• Options
• Examples
• Notes
– Status
– Support

7.1. All Modules 179

F5 Ansible Documentation, Release 1.0.0

Synopsis

• Manage connectors associated with tenants in iWorkflow.

Requirements (on host that executes module)

• f5-sdk >= 2.3.0

• iWorkflow >= 2.1.0

Options

Examples

- name: Register connector to tenant

iworkflow_tenant_connector:
tenant: "tenant-foo"
connector: "connector-foo"
server: "iwf.mydomain.com"
user: "admin"
password: "secret"
validate_certs: "no"
state: "present"

- name: Register multiple connectors to tenant

iworkflow_tenant_connector:
tenant: "tenant-foo"
connector: "{{ item }}"
server: "iwf.mydomain.com"
user: "admin"
password: "secret"
validate_certs: "no"
state: "present"
with_items:
- "connector-one"
- "connector-two"

- name: Unregister connector from tenant

iworkflow_tenant_connector:
tenant: "tenant-foo"
connector: "connector-foo"
server: "iwf.mydomain.com"
user: "admin"
password: "secret"
validate_certs: "no"
state: "absent"

Notes

Note:
• Requires the f5-sdk Python package on the host. This is as easy as pip install f5-sdk.

180 Chapter 7. Module Index

F5 Ansible Documentation, Release 1.0.0

• Tenants are not useful unless you associate them with a connector using the
iworkflow_tenant_connector module.
• For more information on using Ansible to manage F5 Networks devices see https://www.ansible.com/ansible-f5.

Status

This module is flagged as preview which means that it is not guaranteed to have a backwards compatible interface.

Support

This module is community maintained without core committer oversight.

7.1.94 iworkflow_user - Manage users in iWorkflow

New in version 2.4.

• Synopsis
• Requirements (on host that executes module)
• Options
• Examples
• Notes
– Status
– Support

Synopsis

• Manage users in iWorkflow.

Requirements (on host that executes module)

• f5-sdk >= 2.3.0

• iWorkflow >= 2.1.0

Options

Examples

7.1. All Modules 181

F5 Ansible Documentation, Release 1.0.0

Notes

Status

This module is flagged as preview which means that it is not guaranteed to have a backwards compatible interface.

Support

This module is community maintained without core committer oversight.

Note:
• (D): This marks a module as deprecated, which means a module is kept for backwards compatibility but usage
is discouraged. The module documentation details page may explain more about this rationale.

7.2 Network Modules

7.2.1 F5

182 Chapter 7. Module Index

CHAPTER 8

F5 Networks Contributor License Agreement

Before you start contributing to any project sponsored by F5 Networks, Inc. (F5) on GitHub, you will need to sign a
Contributor License Agreement (CLA).
If you are signing as an individual, we recommend that you talk to your employer (if applicable) before signing the
CLA since some employment agreements may have restrictions on your contributions to other projects. Otherwise by
submitting a CLA you represent that you are legally entitled to grant the licenses recited therein.
If your employer has rights to intellectual property that you create, such as your contributions, you represent that you
have received permission to make contributions on behalf of that employer, that your employer has waived such rights
for your contributions, or that your employer has executed a separate CLA with F5.
If you are signing on behalf of a company, you represent that you are legally entitled to grant the license recited
therein. You represent further that each employee of the entity that submits contributions is authorized to submit such
contributions on behalf of the entity pursuant to the CLA.
Click the link below to download the PDF:
F5 Contributor License Agreement (CLA)

183
F5 Ansible Documentation, Release 1.0.0

184 Chapter 8. F5 Networks Contributor License Agreement

CHAPTER 9

Getting involved

So you want to get involved with this project. Great!

Becoming involved in this project can take a variety of angles. The maintainers spend their time camping this reposi-
tory as well as contributing upstream to the Ansible core product. We can be reached on either forum.
Before you jump feet first in to coding, let me give you some idea of the workload involved in module development.
This is not intended to scare you away, but only to set your expectations.

9.1 What is expected from you

First and foremost, we expect you to bring a good attitude. These modules are developed out of our own personal
interests in Ansible; there is no official team here.
With that said, we want to keep the environment from getting bogged down in a bad mood.
The development of a module will require some effort on your part. Often times the countless reviews might seem
frustrating, but believe us, we do it for good reason.
By becoming involved with developing a module, you’re accepting that your contribution will probably not be accepted
right off the bat. If you’re willing to work with us though, and understand the direction we’re headed in, you will more
than likely find your module landing here.
We expect that you stay up to date with the documentation of this site concerning module development. As time goes
on, things change and new practices are adopted. As this happens, we try to keep the documentation up to date with
these changes.
If you develop a module use an out-of-date convention, we will tell you so upon review. It is then expected that you
take the initiative to fix it.
Part of Ansible’s requirements for this is that the people listed in the author field (usually those who wrote the module)
take responsibility for the ongoing maintenance and support of the module.
Understandably this might be a big issue for you, so we are offering to assist. When your module is merged to our
repo here, we lists ourselves as one of the authors of the code.

185
F5 Ansible Documentation, Release 1.0.0

With this in place, and with the addition of us opening the PR with Ansible upstream, we think this will be sufficient
to meet their needs for ongoing maintenance. This is a joint effort though, so lets work together to ensure that the
module stays in Core. Modules that can no longer be supported by their authors are removed from Ansible.

9.2 What to work on

While module development is the primary focus of most contributors, it’s understandable that you may not know how
to write Python, or may not have any interest in writing code to begin with.
That’s ok. Here are some existing things you can do to assist.

9.2.1 Documentation

This is always needed. I write documentation that focuses on many of the moving parts here, but I can’t cover it all
and will inevitably miss things.
Submitting documentation improvements is encouraged.

9.2.2 Unit tests

The unit tests in the test/ directory can always use more love. Unit tests run fast and so more of them is not a burden
on the test runner.
Add more test cases for your particular usage scenarios or any scenarios that may have been missed.
I personally only add enough unit tests to be reasonably comfortable that the code will execute right. This, unfortu-
nately, does not cover many of the functional test cases. So writing unit test versions of functional tests is of huge
benefit.

9.2.3 New module ideas

We don’t have modules to cover all of the ways our products are used. If you find that a module is missing from the
repo and you think needs to be added, I will entertain those ideas on the Github Issues page

9.2.4 New functionality for an existing module

Even the existing modules do not cover all the bells and whistles that customers use.
If a module is missing a parameter that you think it should have, raise and issue and we will consider it.

9.2.5 Postman collections

The Ansible modules make use of the F5 Python SDK for all of their work. In the SDK, all work is accomplished via
the product REST APIs and this just happens to fit in perfectly with the tool Postman.
If you want to help us work on new modules without involving yourself in Python code, a great way to start is to write
Postman collections for the APIs that configure on the BIG-IP what you want to configure.
If you provide us with the Postman collections, this makes it really easy for us to write the Ansible module itself.
This is the approach that many of the F5 teams who do not work in software land all day long take because it is super
effective. Bonus points for collections that address differences in APIs between versions of BIG-IP

186 Chapter 9. Getting involved

F5 Ansible Documentation, Release 1.0.0

9.2.6 Finding bugs (via usage)

Using the modules is the best way to iron out bugs. By using the modules in the way that you expect them to work is
a great way to find bugs.
During the development process, we write tests with specific user personas in mind. Your usage patterns may not
reflect those personas though and that might break the module.
Using the modules is the best way to get both code and documentation correct. If it’s not obvious to you via the
documentation about how a module works, then I guarantee it is unclear to many more people.
Righting those wrongs helps you and future users.

9.2.7 More example playbooks

Playbooks show people how to make use of the module when paired with other modules. Playbooks also are the way
that people inevitably use all these modules, so if you write playbooks that make use of them, this allows people to
copy/paste the actual usage for their own benefit.

9.2.8 More roles for f5devcentral

Ansible’s role features provide the opportunity for us to build new sets of configuration for an F5 product.
There has been some effort to begin writing role that would be useful for different scenarios (such as the bigip-
hardening role) but this effort has not been fully tackle yet.
Anyone can write roles as they are just collections of files, templates, modules, and tasks that you are already writing
for some purpose.
Writing more roles helps spread the usage of the modules.

9.2.9 More ways if you’re at F5

If you’re an F5 employee, there are even more ways to help. Refer to the go/ansible link for more details.

9.3 Keeping F5 out of “legacy” files

When Ansible introduces some new check that causes a whole lot of errors (such as when they added pep8 checking)
they put all of the findings in a legacy file and fix the code that they’re interested.
On one hand, this allows them to fix what they need to fix.
On the other hand, it results in problems like this
ERROR: build/lib/ansible/modules/system/capabilities.py:139:55: E202 whitespace
˓→before ']'

ERROR: build/lib/ansible/modules/system/capabilities.py:166:1: E302 expected 2 blank

˓→lines, found 1

ERROR: build/lib/ansible/modules/system/capabilities.py:170:22: E251 unexpected

˓→spaces around keyword / parameter equals

ERROR: build/lib/ansible/modules/system/capabilities.py:170:24: E251 unexpected

˓→spaces around keyword / parameter equals

... 10,000+ lines here ...

ERROR: build/lib/ansible/playbook/base.py:450:28: E225 missing whitespace around
˓→operator

9.3. Keeping F5 out of “legacy” files 187

F5 Ansible Documentation, Release 1.0.0

ERROR: build/lib/ansible/playbook/base.py:452:28: E225 missing whitespace around

˓→operator

ERROR: The 1 sanity test(s) listed below (out of 1) failed. See error output above
˓→for details.

It turns out that there is some post-processing that happens to whittle down this huge list. What is post-processed is
enumerated here
• local/ansible/test/sanity/pep8/legacy-ignore.txt
While this ends up limiting the amount of errors that are raised by automated testing, it also puts a bandage over the
problem without fixing the actual problems.
I consider this a poor excuse for a “fix”. So it’s your, or our, job to make sure that F5 anything never makes it in this
list. But it doesn’t stop there.
As a good netizen, it is also your job to assist in eliminating these legacy files (the text files, not the modules) by
FIXING all the errors that are raised.
Ultimately, this makes F5’s job easier because when we run the commands to check for this stuff, we’re no longer
seeing a hundred-bajillion errors being raised by their tools.

9.4 Conclusion

One final thing that will require effort on your part that, frankly, we cannot help with, is that of endorsement.
The Ansible work here is by no means supported by F5. If you want that to change, then you will need to initiate that
change. Speaking with your SEs, AMs, SAs, etc etc, is the best way to drive that change.
When we run our mouths about orchestration tools, it falls on deaf ears. If this is valuable to your organization, then
say so.

188 Chapter 9. Getting involved

CHAPTER 10

Guidelines

Guidelines are written for you, the contributor, to understand what we expect from our contributors and to provide
guidance on the direction we are taking the modules.

10.1 Getting Started

Since Ansible 2.2, it is a requirement that all new F5 modules are written to use the f5-sdk.
Prior to 2.2, modules may of been written in bigsuds or requests (for SOAP and REST respectively). Modules
written using bigsuds can continue to be extended using it.
Backward compatibility of older modules should be maintained, but because bigsuds and f5-sdk can co-exist, it
is recommended that all future features be written using f5-sdk.
BIG-IP’s have two API interfaces; SOAP and REST. As a general rule of thumb, the SOAP API should be considered
deprecated. While this is not an official stance from F5, there is clearly more of a push in the REST direction than the
SOAP direction.
New functionality to the SOAP interface continues to be added, but only under certain circumstances.

10.2 Bug fixing

If you are writing a bugfix for a module that uses bigsuds, you should continue to use bigsuds to maintain
backward compatibility.
If you are adding new functionality to an existing module that uses bigsuds but the new functionality requires
f5-sdk, you may add it using f5-sdk.

10.2.1 Naming your module

Base the name of the module on the part of BIG-IP that the modules manipulates. (A good rule of thumb is to refer to
the API being used in the f5-sdk).

189
F5 Ansible Documentation, Release 1.0.0

Don’t further abbreviate names - if something is a well known abbreviation due to it being a major component of
BIG-IP, that’s fine, but don’t create new ones independently (e.g. LTM, GTM, ASM, etc. are fine)

10.3 Adding new features

If a module that you need does not yet exist, it is equally likely that the REST API in the f5-sdk has also not yet been
developed. Please refer to the following github project
• https://github.com/F5Networks/f5-common-python
Open an Issue with that project to add the necessary APIs so that a proper Ansible module can be written to use them.

10.4 Using f5-sdk

The following guidelines pertain to how you should use the f5-sdk in the modules that you develop. We’ll focus on
the most common scenarios that you will encounter.

10.4.1 Importing

Wrap import statements in a try block and fail the module later if the import fails.

f5-sdk

try:
from f5.bigip import ManagementRoot
from f5.bigip.contexts import TransactionContextManager
HAS_F5SDK = True
except ImportError:
HAS_F5SDK = False

def main():

if not HAS_F5SDK:
module.fail_json(msg='f5-sdk required for this module')

You might ask yourself “Why am I doing this?”.

The answer is because of the way that Ansible tests PRs that are made against their source. There are automated
tests that run specifically against your module, using an environment where none of your module’s dependencies are
installed.
Therefore, without the appropriate exception handlers, your PR will fail to pass when these upstream tests are run.
Example tests include, but are not limited to,
• ansible-test sanity –test import –python 2.6
• ansible-test sanity –test import –python 2.7
• ansible-test sanity –test import –python 3.5
• ansible-test sanity –test import –python 3.6

190 Chapter 10. Guidelines

F5 Ansible Documentation, Release 1.0.0

10.4.2 Connecting to a BIG-IP

Connecting to an F5 product is handled for you automatically. You can control which product you are communicating
with by changing the appropriate value in your ArgumentSpec class.
For example, to specify that your module is one that communicates with a BIG-IP, The minimum viable ArgumentSpec
you can write is illustrated below.

class ArgumentSpec(object):
def __init__(self):
self.argument_spec = dict()
self.f5_product_name = 'bigip'

Note the special key f5_product_name. By changing this value, you are able to change the ManagementRoot which
will be provided to your module.
The following is a list of allowed values for this key
• bigip
• bigiq
• iworkflow
Inside your module, the ManagementRoot is contained in the ModuleManager under the self.client.api object.
Use of the object is done in the same way that you work normally use the ManagementRoot of an F5-SDK product.
For example, the code snippet below illustrates a “normal” method of using the F5-SDK

mr = ManagementRoot("localhost", "admin", "admin", port='10443')

vs = mr.tm.ltm.virtuals.virtual.load(name='asdf')

The equivalent Ansible module code is shown below

# Assumes you provided "bigip" in your ArgumentSpec

vs = self.client.api.tm.ltm.virtuals.virtual.load(name='asdf')

10.4.3 Exception Handling

If an exception is thrown, it is up to you decide how to handle it.

For raising exceptions the exception class, F5ModuleError, provided with the f5-sdk is used exclusively. It can be
used as such.

# Module code
...

try:
result = self.want.api.tm.ltm.pools.pool.create(foo='bar')
except iControlUnexpectedHTTPError as ex:
raise F5ModuleError(str(ex))

...
# End of module code

In all cases which you encounter it, it is correct to catch internal exceptions and re-raise them (if necessary) with the
F5ModuleError class.

10.4. Using f5-sdk 191

F5 Ansible Documentation, Release 1.0.0

10.5 Code compatibility

The python code underlying the Ansible modules should be written to be compatible with both Python 2.7 and 3.
The travis configuration contained in this repo will verify that your modules are compatible with both versions. Use
the following cheat-sheet to write compatible code.
• http://python-future.org/compatible_idioms.html

10.6 Automated testing

It is recommended that you use the testing facilities that we have paired with this repository. When you open PR’s,
our testing tools will run the PR against supported BIG-IP versions in our testing facilities.
By doing using our test harnesses, you do not need to have your own devices or VE instances to do your testing
(although if you do that’s fine).
We currently have the following devices in our test harness
• 12.0.0 (BIGIP-12.0.0.0.0.606)
• 12.1.0 (BIGIP-12.1.0.0.0.1434)
• 12.1.0-hf1 (BIGIP-12.1.0.1.0.1447-HF1)
• 12.1.0-hf2 (BIGIP-12.1.0.2.0.1468-HF2)
• 12.1.1 (BIGIP-12.1.1.0.0.184)
• 12.1.1-hf1 (BIGIP-12.1.1.1.0.196-HF1)
• 12.1.1-hf2 (BIGIP-12.1.1.2.0.204-HF2)
• 12.1.2 (BIGIP-12.1.2.0.0.249)
• 12.1.2-hf1 (BIGIP-12.1.2.1.0.264-HF1)
• 13.0.0 (BIGIP-13.0.0.0.0.1645)
• 13.0.0-hf1 (BIGIP-13.0.0.1.0.1668-HF1)
The above list runs the risk of becoming outdated because the actual source of truth can be found here

192 Chapter 10. Guidelines

CHAPTER 11

Architecture

193
F5 Ansible Documentation, Release 1.0.0

194 Chapter 11. Architecture

CHAPTER 12

Code Conventions

The F5 modules attempt to follow a set of coding conventions that apply to all new and existing modules.
These conventions help new contributors quickly develop new modules. Additionally, they help existing contributors
maintain the current modules.

12.1 Style checking

Where possible, we try to automate the validation of these coding conventions so that you are aware of mistakes and
able to fix them yourself without having to have the maintainers intervene.
For more information on what tools perform these checks, refer to the tests page.

12.2 Module Conventions

When writing your modules and their accompanying tests and docs, please follow the below coding conventions.

12.2.1 Use the complex/structure map format

In reference to Jeff Geerling’s page here, this format looks like this.

- name: Create a UCS

bigip_ucs_fetch:
dest: "/tmp/{{ ucs_name }}"
password: "{{ bigip_password }}"
server: "{{ inventory_hostname }}"
src: "{{ ucs_name }}"
user: "{{ bigip_username }}"
validate_certs: "{{ validate_certs }}"
register: result

195
F5 Ansible Documentation, Release 1.0.0

There are several reasons that we use this format. Among them are Geerling’s reasons.
• The structure is all valid YAML, using the structured list/map syntax mentioned in the beginning of this post.
• Strings, booleans, integers, octals, etc. are all preserved (instead of being converted to strings).
• Each parameter must be on its own line, so you can’t chain together mode: 0755, owner: root,
user: root to save space.
• YAML syntax highlighting works slightly better for this format than key=value, since each key will be
highlighted, and values will be displayed as constants, strings, etc.
In addition to those reasons, there are also some situations that, if you use the simple key=value format will raise
syntax errors. Finally, it saves on space and, in the maintainers opinion, is easier to read and know (by looking) what
the arguments to the module are.

12.2.2 Alphabetize your module parameters

The parameters to your modules in the Roles and Playbooks that are developed here must be in alphabetic order.
GOOD

- name: My task
bigip_module:
alpha: "foo"
beta: "bar"
gamma: "baz"

BAD

- name: My task
bigip_module:
alpha: "foo"
gamma: "baz"
beta: "bar"

This provides for consistency amongst module usage as well as provides a way to see at a glance if a module has the
correct parameters.

12.2.3 Double-quotes for Strings, no quotes for Numbers

Ansible supports a simple form of typing for your parameters. If there is a value that is a string, it should be represented
as a string using double quotes.
GOOD

- name: My task
bigip_module:
alpha: "foo"
beta: "bar"

BAD

- name: My task
bigip_module:
alpha: foo
beta: bar

196 Chapter 12. Code Conventions

F5 Ansible Documentation, Release 1.0.0

For numeric characters, you should not use any quotes because this can cause some modules to raise ‘type’ errors if
the expected value is a number and you provide it with a number wrapped in quotes
GOOD

- name: My task
bigip_module:
alpha: 1
beta: 100

BAD

- name: My task
bigip_module:
alpha: "1"
beta: "100"

12.2.4 Begin YAML files with a triple-dash

A YAML file usually begins with three dashes. As such, you should have that be a part of your own YAML files.
GOOD

---

- name: My task
bigip_module:
alpha: 1
beta: 100

BAD

- name: My task
bigip_module:
alpha: "1"
beta: "100"

12.2.5 All tasks should have a name

When your Playbooks encounter errors, the name of the task is always called out in the failure. If you do not provide
a name, then Ansible creates a name for you using the module call itself.
Naming your tasks allows you to quickly reference where a failure occurred.
GOOD

- name: My task
bigip_module:
alpha: 1
beta: 100

BAD

- bigip_module:
alpha: "1"
beta: "100"

12.2. Module Conventions 197

F5 Ansible Documentation, Release 1.0.0

12.2.6 All modules must have a DOCUMENTATION variable

The DOCUMENTATION variable is also required by Ansible upstream as it serves as the source of the module
documentation that is generated on their site.
Good documentation is essential to people being able to use the module so it must be included.
GOOD

DOCUMENTATION = '''
---
module: bigip_device_ntp
short_description: Manage NTP servers on a BIG-IP
description:
- Manage NTP servers on a BIG-IP
version_added: "2.1"
options:
...
'''

BAD

Missing DOCUMENTATION variable

12.2.7 All modules must have an EXAMPLES variable

Useful and valid examples are crucial for people new to Ansible and to the module itself.
When providing examples, be mindful of what you provide. If you developed the module with a specific use case in
mind, be sure to include that use case. It may be applicable to a large majority of users and, therefore, may eliminate
a significant portion of their time that they would otherwise spend figuring out what is or is not needed.
GOOD

EXAMPLES = '''
- name: Set the banner for the SSHD service from a string
bigip_device_sshd:
banner: "enabled"
banner_text: "banner text goes here"
password: "admin"
server: "bigip.localhost.localdomain"
user: "admin"
delegate_to: localhost
'''

BAD

Missing EXAMPLES variable

12.2.8 All modules must have a RETURN variable

The RETURN variable provides documentation essential to determining what, if any, information is returned by the
operation of the module.
End users of the module will reference this documentation when they want to use the register keyword.

198 Chapter 12. Code Conventions

F5 Ansible Documentation, Release 1.0.0

The RETURN field should include the parameters that have been changed by your module. If nothing has been changed,
then no values need be returned.
GOOD

RETURN = '''
full_name:
description: Full name of the user
returned: changed
type: string
sample: "John Doe"
'''

BAD

Missing RETURN variable

If your module does not return any information, then an empty YAML string is sufficient
GOOD
..code-block:: python
RETURN = ‘’‘# ‘’‘

12.2.9 The author field must be a list

There is a good possibility that multiple people will work to maintain the module over time, so it is a good idea to
make the author keyword in your module a list.
GOOD

author:
- Tim Rupp (@caphrim007)

BAD

author: Tim Rupp (@caphrim007)

12.2.10 Author field should be Github handle

Both Ansible and this repository are maintained on Github. Therefore, for maintenance reasons we require your Github
handle. Additionally, your email address may change over time.
GOOD

author:
- Tim Rupp (@caphrim007)

BAD

author:
- Tim Rupp <caphrim007@gmail.com>

12.2. Module Conventions 199

F5 Ansible Documentation, Release 1.0.0

12.2.11 Use 2 spaces in the DOCUMENTATION, EXAMPLES, and RETURN

This is a simple spacing convention to ensure that everything is properly spaced over.
GOOD

options:
server:
description:
- BIG-IP host
required: true
user:
^^

BAD

options:
server:
description:
- BIG-IP host
required: true
user:
^^^^

12.2.12 Use ansible lookup plugins where appropriate

Ansible provides existing facilities that can be used to read in file contents to a module’s parameters.
If your module can accept a string or a file containing a string, then assume that users will be using the lookup plugins.
For example, SSL files are typically strings. SSH keys are also strings even if they are contained in a file. Therefore,
you would delegate the fetching of the string data to a lookup plugin.
There should be no need to use the python open facility to read in the file.
GOOD

some_module:
string_param: "{{ lookup('file', '/path/to/file') }}"

BAD

some_module:
param: "/path/to/file"

12.2.13 Always expand lists in the various documentation variables

When listing examples or documentation in any of the following variables,

• DOCUMENTATION
• RETURN
• EXAMPLES
be sure to always expand lists of values if that key takes a list value.
GOOD

200 Chapter 12. Code Conventions

F5 Ansible Documentation, Release 1.0.0

options:
state:
description:
- The state of things
choices:
- present
- absent

BAD
options:
state:
description:
- The state of things
choices: ['enabled', 'disabled']

12.2.14 Support for 12.0.0 or greater at this time

In the DOCUMENTATION section notes, you should specify what version of BIG-IP the module requires.
At this time, that version is 12.0.0, so your DOCUMENTATION string should reflect that.
GOOD
notes:
- Requires BIG-IP version 12.0.0 or greater

BAD
Any version less than 12.0.0.

If your module requires functionality greater than 12.0.0 it is also acceptable to specify that in the DOCUMENTATION
block.

12.2.15 Never raise a general Exception

General Exceptions are bad because they hide unknown errors from you, the developer. If a bug report comes in and
is being caused by an exception that you do not handle, it will be exceedingly difficult to debug it.
Instead, only catch the F5ModuleError exception that is provided by the f5-sdk. Specifically raise this module and
handle those errors. If an unknown error occurs, a full traceback will be produced that will more easily allow you to
debug the problem.
GOOD
try:
// do some things here that can cause an Exception
except bigsuds.OperationFailed as e:
raise F5ModuleError('Error on setting profiles : %s' % e)

GOOD
if foo:
// assume something successful happens here
else:
raise F5ModuleError('Error on baz')

12.2. Module Conventions 201

F5 Ansible Documentation, Release 1.0.0

BAD

try:
// do some things here that can cause an Exception
except bigsuds.OperationFailed as e:
raise Exception('Error on setting profiles : %s' % e)

BAD

if foo:
// assume something successful happens here
else:
raise Exception('Error on baz')

12.2.16 All modules must support check mode

Check-mode allows Ansible to run your Playbooks in a dry-mode sort of operation. This is very handy when you want
to run a set of tasks but are not sure what will happen when you do.
Since BIG-IPs are usually considered a sensitive device to handle, there should always be a check-mode implemented
in your module.

12.2.17 Do not use local_action in your EXAMPLES

Some folks like local_action and some folks like delegation. Delegation is more applicable to general-purpose Ansible,
so for that reason I want to get people in the habit of using and understanding it.
Therefore, do not use local_action when defining examples. Instead, use delegate_to.
GOOD

- name: Reset the initial setup screen

bigip_sys_db:
user: "admin"
password: "secret"
server: "lb.mydomain.com"
key: "setup.run"
state: "reset"
delegate_to: localhost

BAD

- name: Reset the initial setup screen

local_action:
module: "bigip_sys_db"
user: "admin"
password: "secret"
server: "lb.mydomain.com"
key: "setup.run"
state: "reset"

12.2.18 Default EXAMPLE parameters

For consistency, always using the following values for the given parameters

202 Chapter 12. Code Conventions

F5 Ansible Documentation, Release 1.0.0

• user: “admin”
• password: “secret”
• server: “lb.mydomain.com”
This allows you to not have to overthink the inclusion of your example.
GOOD

- name: Reset the initial setup screen

bigip_sys_db:
user: "admin"
password: "secret"
server: "lb.mydomain.com"
key: "setup.run"
state: "reset"
delegate_to: localhost

BAD

- name: Reset the initial setup screen

bigip_sys_db:
user: "joe_user"
password: "admin"
server: "bigip.host"
key: "setup.run"
state: "reset"
delegate_to: localhost

12.2.19 Assign before returning

To enable easier debugging when something goes wrong, ensure that you assign values before you return those values.
GOOD

def exists(self):
result = self.client.api.tm.gtm.pools.pool.exists(
name=self.want.name,
partition=self.want.partition
)
return result

BAD

def exists(self):
return self.client.api.tm.gtm.pools.pool.exists(
name=self.want.name,
partition=self.want.partition
)

The reason that the above BAD example is considered bad is that when it comes time to debug the value of a variable,
it requires that you change the code to do an assignment operation anyway.
For example, using q to debug the value of the above requires that you implicitly assign the value of the API call before
you do this,

12.2. Module Conventions 203

F5 Ansible Documentation, Release 1.0.0

...
result = self.client.api....
q.q(result)
...

When the code does not do a assignment, then you are required to change the code before you are able to debug the
code.

12.2.20 Fixed Github issues should have an associated issue-xxxxx.yaml file

When a developer takes on a new issue that requires changes to code to get working, these changes should be tested
with a new functional test yaml file located in the module’s test/integration/PRODUCT/targets directory.
For example.
Consider the Github Issue 59 which is relevant to the bigip_virtual_server module.
The developer needed to add new code to the module. So to verify that the new code is tested, the developer should
add a new file to the module’s targets directory here
• test/functional/bigip/bigip_virtual_server/tasks
The name of the file should be
• issue-59.yaml
And inside of the file should be any and all work that is required to,
• Setup the test
• Perform the test
• Teardown the test
Any issues that are reported on github should follow the same pattern, however the filenames of those modules should
be
• ansible-xxxxx.yaml
So-as not to step on the numeric namespace that is used natively in the f5-ansible repository.

12.2.21 RETURN value when there is no return

The correct way to set a RETURN variable whose module has no returnable things is like this according to bcoca.

12.2.22 Excluding code from unit test coverage

Ansible’s test runner makes use of pytest, so the acceptable way of excluding lines from code coverage is documented
here.
• http://coverage.readthedocs.io/en/coverage-4.2/excluding.html
The cases where you would want to use this include the various *_on_device and *_from_device methods in modules
that make direct calls to the remote BIG-IPs.

204 Chapter 12. Code Conventions

F5 Ansible Documentation, Release 1.0.0

12.2.23 Exception message should be on a new line

This convention is done to eliminate the total number of columns in use, but also to increase readability when long
lines tend to scroll off screen. Even with a 160 column limit for this project, long lines, and many lines, can begin to
grow less compact.
BAD
GOOD

12.2.24 List contents should start on a new line

For the same reason given above concerning compactness, lists should follow the same rule. The ending bracket should
be on a new line as well, aligned with the beginning of the variable name
BAD
GOOD

License header

Each module requires a license header which includes the GPL3 license.
Here is the common license header.
If the module under development is your original work, then you can include your name in the copyright above.
If you are only contributing an existing module, then it is not necessary to include a copyright line at the top. Instead,
accepting the F5 CLA is sufficient to get code merged into our branch.

The ANSIBLE_METADATA variable

This variable should be included first in your module. It specifies metadata for the module itself. It can always look
the same. Here is it as would be defined in code.

ANSIBLE_METADATA = {'status': ['preview'],

'supported_by': 'community',
'version': '1.0'}

The stubber will create this for you automatically.

Do not include required key for non-required parameters

This convention comes to us courtesy of Ansible module authoring rules. This convention is used to limit the amount
of verbosity in module code. Additionally, there is a risk of conflict (who is right? docs? or code?) that can occur if
this convention is not followed.
Ansible, by default, make a parameter not required. Therefore, it is also redundant to provide it again in your docu-
mentation.
BAD

...
login:
description:
- Specifies, when checked C(enabled), that the system accepts SSH

12.2. Module Conventions 205

F5 Ansible Documentation, Release 1.0.0

communications.
choices:
- enabled
- disabled
required: False
...

GODE

...
login:
description:
- Specifies, when checked C(enabled), that the system accepts SSH
communications.
choices:
- enabled
- disabled
...

Do not include default key for parameters without defaults

Another convention from Ansible, similar to the required: False convention, this convention is applying the rule to the
default. Since default: None is already the value that Ansible uses (in code), it is redundant to provide it again in the
docs.
BAD

...
login:
description:
- Specifies, when checked C(enabled), that the system accepts SSH
communications.
choices:
- enabled
- disabled
default: None
...

GODE

...
login:
description:
- Specifies, when checked C(enabled), that the system accepts SSH
communications.
choices:
- enabled
- disabled
...

Do not decompose to a *_device method if the using method is itself an *_device method

This convention is in place to limit the total amount of function decomposition that you will inevitably try to put into
the code. Some level of decomposition is good because it isolated the code that targets the device (what we refer to as
*_device methods) from the code in the module that does not communicate with the device.

206 Chapter 12. Code Conventions

F5 Ansible Documentation, Release 1.0.0

This method of isolation is how we extend modules when there is a divergence in the API code, or when the means of
transporting information from and to the device changes.
You can take this decomposition too far though. Refer to the examples below for an illustration of this. When you go
to far, the correction is to merge the two methods.
BAD
GOOD
This convention remains valid when the particular line of code that you are using is a single line. Therefore, if the
upload_file line were used in many places in the code, it is still correct to merge the methods instead of having a
different method for it.
The only time when it would be correct to decompose it is if the “other” methods were not *_device methods.

12.2. Module Conventions 207

F5 Ansible Documentation, Release 1.0.0

208 Chapter 12. Code Conventions

CHAPTER 13

Upstreaming

Upstreaming refers to opening a PR with the Ansible core product.

Our goal with this repository is to serve as an incubator for modules to mature. Eventually, we hope that the modules
here will find their way to the upstream Ansible product (core or extras).

13.1 Incubating modules

Modules that are currently in incubation are named as normal modules are that you would find in the Ansible product.
They are easily distinguished by their filename not including a leading underscore.
These modules can only be obtained through the installation steps outlined in the ‘Installation‘_ docs.
An incubating module may or may not be working at any point in time. While we prefer to not break any of them
during development, we recognize that sometimes that is part of the process.

Note: Just because a module is incubation does not mean that it is unstable. Many modules remain in the incubator
because there has not been sufficient interest from the community either internal or external to release them.

A module in incubation should have an associated Issue in Github so that its progress can be tracked and so that others
do not repeat work.

13.2 Qualifications for upstreaming

A module is considered to be in a mature state once it has met all of the standards that have been established for it.
• http://docs.ansible.com/ansible/dev_guide/testing.html
• ‘upstreaming requirements‘_
• ‘coding conventions‘_

209
F5 Ansible Documentation, Release 1.0.0

At that point in its development, we will make the request to upstream Ansible for the module’s inclusion.

13.3 Releases

After a module is upstreamed, there will continue to be a period of time that must pass before it is released as part of
the core Ansible product.
That release schedule is shown in the ROADMAP files near the top of each file.
Depending on what version is currently stable, upstreamed modules will be part of the next major stable release.
For example.
If 2.3 is the current stable version and a module was upstreamed to core, it would not appear as part of pip install
ansible until version 2.4 was released.
You can get the modules before that point in time, but you must do so manually. The link to the ‘stable modules is
here‘_.

210 Chapter 13. Upstreaming

CHAPTER 14

Upstreaming Process

The upstreaming process is summarized below. Only one person should be concerned with upstreaming things.

14.1 Upstream Github template

Ansible provides an Issue template that will be shown to you automatically when you create a new PR in Github. You
should fill out the various fields in it, making sure to include the following in one of the “Summary”, “Description”,
or related fields.
Below is an example of what has been provided in the past and you should use it as an example of what you too should
provide.
Including the extra information that shows your due diligence in writing and testing the module is important because
it helps ensure the Ansible maintainers, and our customers, that the code has been written well.

14.2 Upstream Window

Generally speaking the upstreaming window is open each one week around the times of the Networking meeting. Here
is the Networking team’s schedule.
• https://github.com/ansible/community/blob/master/MEETINGS.md#wednesdays
During that time, you will need to comment on the Ansible Networking Groups issue tracker for new PRs. This can
be found here.
• https://github.com/ansible/community/issues/110

14.3 Upstream Meeting

The Networking team will address your PRs at their weekly meeting, which you are expected to attend.

211
F5 Ansible Documentation, Release 1.0.0

The meeting can be found on IRC at the below location

• Server: irc.freenode.net
• Channel: #ansible-devel

212 Chapter 14. Upstreaming Process

CHAPTER 15

Writing a Module

Let’s explore what it takes to write a module using the provided guidelines and standards.

15.1 Getting Started

The first step is to decide what you will call your module. For this tutorial we will recreate the functionality of
the bigip_device_sshd module as it provides good examples of the common idioms you will encounter when
developing or maintaining modules.
Because this module already exists, let’s just slightly change the name of our module to the following
bigip_device_ssh
This name will additionally prevent you from tab’ing to the existing sshd module.

15.2 Create the directory layout

There are a number of files and directories that need to be created to hold the various tests and validation code in
addition to just your module.
To create the necessary directories and files, an executable file is available for you to use to set these directories up
automatically.
$> ./devtools/bin/stubber.py --module MODULE_NAME stub

When it finishes running, you will have the necessary files available to begin working on your module.

15.3 Stubbed files

The stubber creates a number of files that you need to then go through and do some form of development on. These
files are

213
F5 Ansible Documentation, Release 1.0.0

• docs/modules/MODULE_NAME.rst
• library/MODULE_NAME.py
• test/integration/MODULE_NAME.yaml
• test/integration/targets/MODULE_NAME/
• test/unit/bigip/test_MODULE_NAME.py

15.3.1 The DOCUMENTATION variable

The next chunk of code that you will insert describes the module, what parameters is accepts, who the au-
thors/maintainers are, its dependencies, etc.
Let’s look at the code that we will add to our module.

DOCUMENTATION = '''
---
module: bigip_device_sshd
short_description: Manage the SSHD settings of a BIG-IP
description:
- Manage the SSHD settings of a BIG-IP
version_added: "2.5"
options:
banner:
description:
- Whether to enable the banner or not
choices:
- enabled
- disabled
banner_text:
description:
- Specifies the text to include on the pre-login banner that displays
when a user attempts to login to the system using SSH
inactivity_timeout:
description:
- Specifies the number of seconds before inactivity causes an SSH
session to log out
log_level:
description:
- Specifies the minimum SSHD message level to include in the system log
choices:
- debug
- debug1
- debug2
- debug3
- error
- fatal
- info
- quiet
- verbose
login:
description:
- Specifies, when checked C(enabled), that the system accepts SSH
communications
port:
description:
- Port that you want the SSH daemon to run on

214 Chapter 15. Writing a Module

F5 Ansible Documentation, Release 1.0.0

notes:
- Requires the f5-sdk Python package on the host This is as easy as pip
install f5-sdk
extends_documentation_fragment: f5
requirements:
- f5-sdk
author:
- Tim Rupp (@caphrim007)
'''

Most documentation variables have a common set of keys and only differ in the values of those keys.
The keys that one commonly finds are
• module
• short_description
• description
• version_added
• options
• notes
• requirements
• author
• extends_documentation_fragment

Note: The extends_documentation_fragment key is special as it is what will automatically inject the variables user,
password, server, server_port and validate_certs into your documentation. It should be used for all modules.

Additionally, you should take note that Ansible upstream has several rules for their documentation blocks. At the time
of this writing, the rules include
• If a parameter is not required, do not include a required: false field in the parameter’s DOCUMENTATION
section.

15.3.2 The EXAMPLES variable

The examples variable contains the most common use cases for this module.
I personally think that setting of the banner will be the most common case, but future authors are free to add to my
examples.
These examples will also serve as a basis for the functional tests that we will write shortly.
For this module, our EXAMPLES variable looks like this.

EXAMPLES = '''
- name: Set the banner for the SSHD service from a string
bigip_device_sshd:
banner: enabled
banner_text: banner text goes here
password: secret
server: lb.mydomain.com
user: admin

15.3. Stubbed files 215

F5 Ansible Documentation, Release 1.0.0

delegate_to: localhost

- name: Set the SSHD service to run on port 2222

bigip_device_sshd:
password: secret
port: 2222
server: lb.mydomain.com
user: admin
delegate_to: localhost
'''

This variable should be placed after the DOCUMENTATION variable.

The examples that you provide should always have the following
delegate_to: localhost
The BIG-IP modules are intended to run on the Ansible controller only. The best practice is to use this delegate_to:
here so that users get in the habit of using it
common args
The common args as as follow
• password should always be set to secret
• server should always be set to lb.mydomain.com
• user should always be set to admin

15.3.3 The RETURN variable

The pattern which we follow is that we always return what changed in the module’s parameters when the module has
finished running.
The parameters that I am referring to here are the ones that are not considered to be the “standard” parameters to the
F5 modules. Some exceptions to this rule apply. For example, where the state variable contains more states than just
absent and present, such as in the bigip_virtual_server module.
For our module these include,
• banner
• banner_text
• inactivity_timeout
• log_level
• login
The RETURN variable describes these values, specifies when they are returned and provides examples of what the
values returned might look like.

216 Chapter 15. Writing a Module

F5 Ansible Documentation, Release 1.0.0

When the Ansible module documentation is generated, these values are presented in the form of a table. Here is the
RETURN variable that we would place in our module file.

15.3.4 The import block

The next section in our code is the block of code where our ‘import‘s happen.
This code usually just involves importing the module_util helper libraries, but may also include imports of other
libraries if you are working with legacy code.
For this module our import block is the following

from ansible.module_utils.f5_utils import AnsibleF5Client

from ansible.module_utils.f5_utils import AnsibleF5Parameters
from ansible.module_utils.f5_utils import HAS_F5SDK
from ansible.module_utils.f5_utils import F5ModuleError
from ansible.module_utils.f5_utils import iteritems
from ansible.module_utils.f5_utils import defaultdict

try:
from ansible.module_utils.f5_utils import iControlUnexpectedHTTPError
except ImportError:
HAS_F5SDK = False

In 90% of cases, this code is boilerplate and can be ignored by the developer when writing a module. stubber.py takes
care of this for you.

15.3.5 ModuleManager class

The next block of code is the skeleton for our module’s Manager class. We encapsulate most of our module’s steering
code inside this class. It acts as the traffic cop, determining which path the module should take to reach the desired
outcome.
The Manager class is where the specifics of your code will be. The stubber will create a generic version of this for
you. It is your responsibility to change the API calls as needed.
Below are examples of the different versions of the design standards that have existed at one point or another
• version 3.3 (proposed)
• version 3.2 (current)
• version 3.1
• version 3
• version 2
• version 1

Note: The ModuleManager class will change over time as our design standards change. The above examples are used
for historical reference and training.

For the implementation specifics, refer to the existing module.

A deep dive into the major differences between the different versions of design standards ‘can be found here‘_.

15.3. Stubbed files 217

F5 Ansible Documentation, Release 1.0.0

15.4 Connecting to Ansible

With the implementation details of the module complete, we move on to the code that hooks the module up to Ansible
itself.

15.4.1 The main function

This code begins with the definition of the main function.

This code should be placed __after__ the definition of your class which you wrote earlier. Here is how we begin.

def main():

15.4.2 Argument spec and instantiation

Next, we generate the common argument spec using a utility method of Ansible.

argument_spec = f5_argument_spec()

With the argument_spec generated, we update the values in it to match the options we declared in our
DOCUMENTATION variable earlier.
The values that you must specify here are, again, the ones that are not common to all F5 modules. Below is the code
we need to update our argument_spec

meta_args = dict(
allow=dict(required=False, default=None),
banner=dict(required=False, default=None, choices=CHOICES),
banner_text=dict(required=False, default=None),
inactivity_timeout=dict(required=False, default=None, type='int'),
log_level=dict(required=False, default=None, choices=LEVELS),
login=dict(required=False, default=None, choices=CHOICES),
port=dict(required=False, default=None, type='int')
)
argument_spec.update(meta_args)

After the argument_spec has been updated, we instantiate an instance of our class, providing the
argument_spec and the value that indicates we support Check mode.

module = AnsibleModule(
argument_spec=argument_spec,
supports_check_mode=True
)

All F5 modules must support Check Mode as it allows an administrator to determine whether a change will be made
or not when the module is run against their devices.

15.4.3 Try and module execution

The next block of code that is added is a general execution of your class.
We wrap this execution inside of a try...except statement to ensure that we handle know errors and bubble up known
errors.

218 Chapter 15. Writing a Module

F5 Ansible Documentation, Release 1.0.0

Never include a general Exception handler here because it will hide the details of an unknown exception that we
require when debugging an unhandled exception.

try:
obj = BigIpDeviceSshd(check_mode=module.check_mode, **module.params)
result = obj.flush()

module.exit_json(**result)
except F5ModuleError as e:
module.fail_json(msg=str(e))

15.4.4 Common running

The final two lines in your module inform Python to execute the module’s code if the script being run is itself exe-
cutable.

if __name__ == '__main__':
main()

Due to the way that Ansible works, this means that the main function will be called when the module is sent to the
remote device (or run locally) but will not be called if the module is imported.
You would import the module if you were using it outside of Ansible, or in some sort of test environment where you
do not want the module to actually run.

15.5 Testing

Providing tests with your module is a crucial step for having it merged and subsequently pushed upstream. We rely
heavily on testing.
In this section I will go in to detail on how our tests are organized and how you can write your own to ensure that your
modules works as designed.

15.5.1 Connection variables

It is not required that you specify connection-related variables for each task. These values are provided for you
automatically at the playbook level.
These values include,
• server
• server_port
• user
• password
• validate_certs

15.5.2 Style checks

We make use of the pycodestyle command to ensure that our modules meet certain coding standards and compat-
ibility across Python releases.

15.5. Testing 219

F5 Ansible Documentation, Release 1.0.0

You can run the style tests via the make command

make style

Before submitting your own module, it is recommended that your module pass the style tests we ship with the reposi-
tory. We will ask you to update your code to meet these requirements if it does not.

15.5.3 Integration/Functional tests

This is probably the most important part of testing, so let’s go in to detail on this part.
Functional tests are required during module submission so that we (F5) and you, the developer, can agree that a module
works on a particular platform.
We will test your module on a variety of versions automatically when a new PR is submitted, and from there provide
feedback if something does not fly.

Structure of tests

Test file stubs are created for you automatically when you stub a new module.
First, let’s look at the layout of a set of tests. A test is composed of a role whose name matches the name of the module
that is being tested.
This role is placed in the tests/integration/targets/ directory.
So, for our example, our test role looks like this.
• test/integration/targets/MODULE_NAME/
Inside of this role is everything that you would associate with a normal role in ansible.
Consider the following examples.
• if your test requires static files be used, then a files/ directory should be in your role.
• if your test requires template data (for example iRules) for its input, then a templates/ directory should be in
your role.
• all roles will perform some work to test the module, so a tasks/ directory should be in your role.
Now let’s dig in to what a test should look like.

15.6 Test content

The test itself will follow the pattern below.

• Perform some operation with the module
• Assert a change (and optionally other values)
• Perform the same operation again (identical)
• Assert no change
All of the tests work like this, and it is a decent smoke test for all modules until such time as we take the testing further.
Here is an example of a test from the bigip_device_sshd module.

220 Chapter 15. Writing a Module

F5 Ansible Documentation, Release 1.0.0

---

- name: Set the SSHD allow string to a specific IP

bigip_device_sshd:
allow:
- "{{ allow[0] }}"
register: result

- name: Assert Set the SSHD allow string to a specific IP

assert:
that:
- result|changed

As you can see, pretty straightforward.

We use the module and then we check that the result we register was changed. Tests for idempotence (the last two
bullets above) are shown in the section below.

15.7 Test variables

Information specific to the tests that you need to run should be put in the defaults/main.yaml file of your test role.
By putting them there, you allow individuals to override values in your test by providing arguments to the CLI at
runtime.

15.8 The idempotent test

All tests that change data should also include a test right after it that tries to perform the same test, but whose result is
expected to not change.
These are called idempotent tests because they ensure that the module only changes settings if the setting needs to be
changed.
Here is an example of the previous test as an idempotent test

- name: Set the SSHD allow string to a specific IP - Idempotent check

bigip_device_sshd:
allow:
- "{{ allow[0] }}"
register: result

- name: Assert Set the SSHD allow string to a specific IP - Idempotent check
assert:
that:
- not result|changed

There are two things to note here.

First, the test code itself is identical to the previous test.
Second, note that we changed the name of the test to include the string ‘‘“- Idempotent check”‘. This gives reviewers
the ability to visually note that this is an idempotent test.
Third, note that in our assertion, we are check that the result has not changed. This is the important part because it is
what ensures that the test itself was idempotent.

15.7. Test variables 221

F5 Ansible Documentation, Release 1.0.0

Now lets look at how you call the test.

15.9 Calling the test

To call the test and run it, this repo includes a make command that is available for all modules. The name of the make
target is the name of your module.
So, for our example, that make command would be.
• make bigip_device_ssh
This command will run the module functional tests for you in debug mode.
You may optionally call the tests with the literal ansible-playbook command if you need to do things like,
• stepping (–step)
• starting at a particular task (–start-at-task)
• running tasks by tag name (–tags issue-00239)
To run the tests without make, first, change to the following directory.
• test/integration
Next, find the playbook that matches the module you wish to test. Using this playbook, run ansible-playbook as you
normally would. A hosts file is included for you in the working directory you are in.
An example command might be,

ansible-playbook -i inventory/hosts bigip_device_sshd.yaml

This is the most flexible option during debugging.

15.10 Including supplementary information

If you include files inside of the files/, templates, or other directories in which the content of that file was auto-generated
or pulled from a third party source, you should include a README.md file in your role’s directory.
Inside of this file, you can include steps to reproduce any of the input items that you include in the role subdirectories.
In addition, this place is also a good location to include references to third party file locations if you have included
them in the tests. For example, if you were to include iRules or other things that you downloaded and included from
DevCentral or similar.
The README.md is there for future developers to reference the information needed to re-create any of the inputs to
your tests in case they need to.

15.11 Other testing notes

When writing your tests, you should concern yourself with “undoing” what you previously have done to the test
environment.
Test testing environment (at the time of this writing) boots harnesses for each suite of tests. That means that all tests
are run on the same harness.

222 Chapter 15. Writing a Module

F5 Ansible Documentation, Release 1.0.0

Therefore, any changes you may make in one of the integration tests might accidentally be used as a basis in subse-
quent tests. You do not want this because it makes using additional the ansible-playbook arguments specified above
exceedingly difficult.
Therefore, please cleanup after yourself. Since you need to test the absent case in most cases, this is a good opportunity
to do that.

15.11. Other testing notes 223

F5 Ansible Documentation, Release 1.0.0

224 Chapter 15. Writing a Module

CHAPTER 16

Deprecating Code

Our Ansible modules follow a strategy of deprecation which is intended to give the user of the modules ample time to
upgrade to a new version of Ansible.
New releases of Ansible happen, at the time of this writing, about once a quarter.
With this in mind, the following process should allow a user 3 to 6 months to upgrade their Ansible installation to
the new code. If the user misses this 3 to 6 month period, then they can upgrade incrementally (2.1 -> 2.2 -> 2.3)
instead of upgrading directly to the latest version and, in the process, test that the incremental versions work with their
playbooks.

16.1 Deprecation process

Let’s look at an example deprecation process

• 2.0 - version to deprecate
• 2.1 - deprecated version
• 2.2 - version with deprecated feature removed
During the second release noted above, the module developer MUST insert adequate warnings for the user to see.
Ansible will color warning messages so that they stick out from regular messages.

16.2 Raising deprecated warnings

To raise warnings about deprecated functionality, the module developer should add the following method to their
ModuleManager class.
Additionally, the module developer should add the calling of that method when they collect the changes to report to
the user. For example,

225
F5 Ansible Documentation, Release 1.0.0

And finally, the module developer should populate the __warnings key of their changes attribute as needed. For
example, in the bigip_gtm_wide_ip module, the following is used in the lb_method property when it sees you are
using an option name that is deprecated. For example,
The changes attribute is typically updated during the call to _update_changed_options during update, or
_set_changed_options during create.
If your module needs to detect changes outside of those two general methods, you should be doing so inside of the
should_update method.

Note: To do your own ad-hoc detection inside of should_update, you will need to overload the base classes’ method.
If you do this, you should decide whether or not it is still necessary to call the base classes’ method during the call to
your overloaded method.

With that in place, you will find yourself with warning messages being raised by Ansible when you use the deprecated
functionality.

16.3 Deprecating parameters

Below is an excerpt from how one might deprecate an option that we no longer want to use. You may do this for a
number of reasons, but in most cases it is due to the original name not making sense in the context it is used.
For example, you might have named the original option rules when the more appropriate name for the option would
have been irules.

Note: Ansible allows for aliasing of options so that specifying one is equivalent to specifying another. This is not
the situation that we are referring to here. It is still perfectly acceptable to use option aliases if you want to. These
guidelines are for when you specifically want to remove options that are presumably already in use.

Here is a sample ArgumentSpec from the version where we made the mistake. Let’s assume that this mistake was
made in version 2.0.
Now, we wish to deprecate that option name. So, in version 2.1 of Ansible, we would do something like this.
Additionally, we would include the warnings necessary to make the user of the module aware that they are using
deprecated functionality (the rules option).
Finally, during the release cycle of Ansible 2.2, we would want to change our spec to look like so.
Thus, removing the deprecated functionality.
Also, do not forget to remove any mention of the deprecation inside the actual module code. We don’t want the legacy
code to stick around. This helps keep technical debt at bay.

226 Chapter 16. Deprecating Code

CHAPTER 17

Code Conventions

The following is a document that describes some of the design decisions that went into the F5 Ansible modules and
why they were made. This document is intended to address any contributor, or customer, questions on why I did what
I did and the known limitations for this design.

17.1 SSH is not used. REST is

This is a question that comes up rather frequently.

Why don’t the modules use ssh?
After all, the “other” networking modules use SSH for their communication with their remote devices.
This is a complicated question to answer because there are __many__ reasons why this was decided upon. I will try
to explain all of those reasons below.

17.1.1 TMSH is not an API

At F5, regardless of what you might here or read online, tmsh is not considered to be a formal API.
Now, there are some people who will try to argue about this and justify their argument by saying that, “well, tmsh is a
publicly available way to interact with the BIG-IP, therefore it is implicitly an API”.
While tmsh is indeed a publicly available way to interact with the BIG-IP, it is not considered by anyone at F5 to be
an API. You will notice, compared to other APIs that are formal, that it has none of the features of “real” APIs.
In addition to missing many features of “normal” APIs, it also is not guaranteed to be consistent across versions of
BIG-IP.
You should not rely on tmsh for anything except in cases where you have no other choice. And in those cases, you
must handle the versioning of it yourself.

227
F5 Ansible Documentation, Release 1.0.0

17.1.2 The company had decided to put all their effort into REST

When the REST pattern of API development became popular, F5 put some work into making a REST wrapper around
tmsh. That is what you have today; a wrapper around calls to tmsh.
To understand why the REST API is where the company has put more effort, you need to understand the history of the
SOAP API at F5.
It is surprisingly difficult for a team to develop for the SOAP API. The REST API is easier to code for. Additionally,
the REST APIs curiously map almost directly to the tmsh command you would use. Coincidence? Hardly. Remember,
it’s tmsh.
There is still new functionality being added to SOAP, but most of the engineers at F5 are focused on providing REST
functionality.
• It’s natively built into most all programming languages
• It’s more easily supported in our future javascript-based iAppLX effort
• It’s pretty close to native tmsh

17.1.3 SSH on BIG-IP can cause auth errors when under heavy load

For better or worse, while SSH is about as native today as telnet was in the past, it actually takes a fair amount of
resources to establish an SSH connection to a remote device.
You see this in Ansible today with their use of ControlMaster and pipelining. Ansible saw that just the act of repeatedly
connecting to the remote device over SSH caused a significant amount of lag.
A real-life example, a customer had been using modules (that they had developed) that used SSH under the hood to
connecto the BIG-IP and were seeing “F5 Authorization Required” 95% of the time. With SOAP this dropped to 4%
and with REST this dropped to 1%.
When we investigated things further, we noticed that when the BIG-IP was under load, the normal behavior of Ansible,
namely this,
sshpass -d57 ssh -C -o ControlMaster=auto -o ControlPersist=60s
-o StrictHostKeyChecking=no -o User=ansible -o ConnectTimeout=10 -o
ControlPath=/tmp/ansible_tower_JR8zTS/cp/ansible-ssh-%h-%p-%r -tt
10.192.73.218 'tmsh delete sys connection'

When set in an infinite loop would cause failures rather consistently.

Diagnosis? The act of SSH’ing to frequently to BIG-IP causes intermittent authentication failures. Solution? Don’t
use SSH because it’s resource-intensive “enough” to be unreliable for things that need to be reliable.
Now, this creates an issue. By giving up SSH, you also implicitly give up on SSH certificate based access. Many
customers made a stink about this. Well, on one hand their frustration is justified. On the other hand though, it would
be a herculean amount of work to support SSH.
First, because of the above problem, but also because,
• You don’t always have root shell access to your box. The cloud versions of BIG-IP come with “Appliance
mode” turned on which puts you directly into tmsh
• tmsh has no structured output format like JSON. There’s no consistent way to parse tmsh output. This means we
would have to commit serious amounts of code to, ultimately, poorly parsing free-form text output. This would
impact how long it took us to bring new modules to market and how reliably we could do that.
• The tmsh commands and output changes across nearly all versions of BIG-IP
• There is no SDK to consistently interact with tmsh

228 Chapter 17. Code Conventions

F5 Ansible Documentation, Release 1.0.0

17.1.4 REST is, frankly, easy to code for

This constraint is relevant to the developers who actually code these modules. For the first iteration of the modules,
what I refer to 1st-gen, the modules were written by primarily two people who were not F5 employees.
For the 2nd-gen modules, they were all written by one guy; me, an F5 employee. This was when F5 began put more
skin in the Ansible game.
For the 3rd-gen modules, they were written primarily by myself and one other F5 employee. Then, they were tested
and promoted by several other F5 employees.
The reason that I bring these points up is to emphasize just how __few__ people are actually working on the modules
that you are using.
There is no “Ansible team” at F5. Due to my limited resources, I placed a priority on ease-of-development and testing.
I needed to churn reliable product out at a rather fast pace compared to the pace that all other F5 products are released.
My timeline was weeks, not bi-yearly like BIG-IP releases.
SOAP has different APIs for every configuration point. Literally. If you need to set the description of a Virtual Server,
you need to use the set_description API, but if you need to set a destination of the same Virtual Server you need to use
the set_destination_v2 API. It’s v2 because there is also a set_destination API that must be used for anything before
version 11 of BIG-IP.
This is kinda frustrating from a developer point of view because you need to know all these different APIs.
It’s frustrating from the admin’s point of view because each API is another round-trip to the BIG-IP. Each time we
need to talk to BIG-IP it means a slow-down and a chance that a failure could happen.
This can be worked around through the use of Transactions in SOAP, but that just _another_ thing that the users of the
API need to be aware of when writing any sort of integrations with BIG-IP.
REST configures based on a “resource” so many APIs are implicitly transactional without needing to use transactions.
Additionally, these resources mean that you only need to refer to __one__ API when changing most things about a
particular object in BIG-IP.
For example, using our virtual server example above, instead of 2 or more APIs, there is only one;
/mgmt/tm/ltm/virtual. Sending a GET request to the resource returns a single JSON payload where you can change the
description or destination as needed and then send a PATCH back to the BIG-IP with those changed values.
Also, it works like this across __all__ of the resources in BIG-IP. Which means once you have learned how to use one
resource, you’ve essentially learned how to use all of them.

Note: It should be noted that due to bugs in the REST API this is not __always__ true, but it is true enough that you
can consider it “the way things are” and handle the edge cases as you encounter them. Indeed, we handle just such
edge cases for you in the f5-sdk so that you don’t need to care. That is one of the many reasons to use the SDK; we
iron out the inconsistencies in the API.

From a developer point-of-view, this requirement to learn a convention instead of learning a library of API calls means
that new developers can be onboarded more quickly and existing developers can more easily add new functionality
and support existing functionality.
From an admin point of view, this means that we need to make fewer round-trips to your BIG-IP and this should
therefore speed up the operations that we do perform on the BIG-IP.

17.1.5 The F5 Python SDK is built on REST

The tool underlying all future Ansible F5 module development is the F5 Python SDK.

17.1. SSH is not used. REST is 229

F5 Ansible Documentation, Release 1.0.0

First, some history of this SDK.

F5 is notorious for writing half-baked “SDKs”. These “SDKs” always have the following things in common.
• Written by one engineer
• The “SDK” covers Pools, Virtuals, and pool members
• The engineer has left the company
• No resources were ever dedicated to the “SDK”
I didnt want this to be the same story with the Python SDK that had been developed by the OpenStack team. Since the
OpenStack integration was a project at F5 that had real resources dedicated to it, and the OpenStack integration relied
implicitly on the Python SDK, it was safe-enough to consider the Python SDK “supported”.
I wanted to further re-enforce the need to keep this SDK alive though, so I chose to build all the Ansible modules to
use it. My hope was that if one project (OpenStack) had resources dedicated to it, then maybe I could get a second
major project (Ansible) to also get resources dedicated to it to give the SDK a greater chance of surviving.
I also wanted to focus developer effort and expertise instead of fragmenting it unnecessarily. My goal was that more
engineers contributing to this SDK would negate the need for fragmenting this development effort and that we would
ultimately be building everything off of this one SDK and dog-fooding it appropriately.
REST was also chosen because native ability to speak “REST via HTTP” is built into all programming languages these
days. We were using Python in this case, but it is not much of a leap to expand this same functionality to Ruby or Go
or JavaScript or any language you may be interested in. All of them have native support for speaking HTTP.
Another reason to use this REST SDK is that it is easy to debug JSON payloads with common toolchains. For instance,
working with Chrome developer tools, Postman, or other REST clients is simple. SOAP envelopes are more difficult
to humanly consume as they are usually in an XML formatted payload and it’s not readily obvious what tools one
would use to send payloads like this back and forth to a BIG-IP.
Finally, the Python packages suds and bigsuds are not Python 3 compatible, and (at least in bigsuds case) supported
or used by anyone at F5. There was no demand for building an SDK that supported an API that only a minority of
colleagues was using at F5 or in the community.

17.1.6 Other F5 products made REST a first-class citizen

BIG-IP is not F5’s only product. BIG-IQ and iWorkflow are two other products that we make. Both of these products
natively use REST API communication for __all__ of their functionality.
Indeed, if you use a network inspector like those built-into Chrome or Firefox, you can see the actual APIs these F5
products communicate with and the payloads that they use.
Ok, fine, but “these products ship on something that has SSH access” you might say. That’s true, but in the future they
won’t. Teams developing these products are rapidly turning them into standalone applications; what we refer to as
“TMOS independence”.
So in the future they will __not__ have CLI’s other than whatever is provided by the operating system that hosts them.
Also, each of these products provides functionality that allows they to proxy requests directly to the BIG-IPs that they
manage. We refer to this as “REST Proxy”. That these tools provide such native support is testament to how REST is
considered to be a first-class citizen for configuring our devices.

17.1.7 Other vendor APIs are always REST-like

If you look at the API landscape, nearly every vendor API is REST-like. It’s becoming increasingly uncommon to see
SOAP APIs because, compared to JSON-over-HTTP using HTTP verbs, SOAP is just a little too heavy-handed.

230 Chapter 17. Code Conventions

F5 Ansible Documentation, Release 1.0.0

Most applications can represent their data structures just fine using JSON. Its largely unnecessary to provide anything
bigger than just a JSON payload. Languages can natively transform scalars, lists, and dictionaries to the data structures
native to the language.
Indeed, even in a complicated system like BIG-IP, all of our data structures can be represented by a JSON payload.
To make the adoption of our APIs easier for those admining our box and integrating with it, it was important to use
technology that was already familiar to them.
Since customers are already largely exposed to REST-like APIs from their dealings with other vendors, it was natural
to make use of the REST API instead of some other format, or, direct SSH communication.

17.1.8 The people working on this codebase work with REST and the SDK every
day

The F5 OpenStack team began the trend of SDK development with their work on our Openstack integration. This
progressed to include my adopting their work in Ansible. Today, the people who are working on Ansible modules are
the same developers who were initially working on the F5 Python SDK.
Furthermore, we are introducing more teams at F5 to the Python SDK so that they too may integrate it into their testing
procedures.
So as you can see, the majority of the new work being done at F5 is being done by people who are familiar with REST.
There is a sizable amount of pre-existing work in test harnesses and other stuff at F5 that is based on SSH, but the
experts that were involved in writing that have since left the company and no expertise exists to further develop it; nor
do those teams want to put further development into it.
With this increasing body of knowledge around our REST API, it makes less sense to attempt to support SSH.

17.1.9 The Ansible persistent network connection was not mature at the time

Persistent network device connections was released in Ansible 2.3. A __significant__ amount of work on the modules
however, had already been done prior to this release.
To expect that one guy (Tim) to,
• change all those 30 modules
• support both modes (API and SSH) of configuring the remote device
• that had taken multiple years to write
was not something I wanted to undertake.
I honestly leave this open as an exercise for the end user. If you are deeply interested in making SSH happen, then by
all means go after it. Modules that come out of F5 directly though will remain REST based for the foreseeable future.

17.1. SSH is not used. REST is 231

F5 Ansible Documentation, Release 1.0.0

232 Chapter 17. Code Conventions

CHAPTER 18

Dealing with “replace all”

A common ask from customers and colleagues is to mimic the behavior of the “replace-all-with” tmsh functionality
via Ansible modules. The following document discusses challenges and proposes solutions for this feature when it is
requested.

18.1 Challenges

By it’s nature, Ansible is not designed to support something such as replace-all-with. Ansible modules are normally
intended to be run per-device and therefore should, in most cases, be accepting a single item of configuration and
applying it per that device.
For example,
The above task, iterated per host, would create a number of SNAT pools. There is the desire, however, to remove all
the existing and replace with a new list. Suppose that you did not know what the existing SNAT pools were. In that
case, how would you remove the existing to add new ones?
This pattern of “unit of work per host” becomes an anti-pattern when applied to replace-all-with. This is because there
is no way to reliably tell the module to
• Delete all the existing
• Add what I give you
Since the module only knows about what it receives at time of execution and not about what the Play is doing as a
whole (or even that its in a loop) you cannot specify, for example a replace_all_with parameter.
It’s also unacceptable to have something like an append parameter because, again, the module is not aware that it is in
a loop or what the greater Play is doing.
There may be some ability to make the module aware by specifying these list squashing modules in Ansible’s default
squash_actions configuration variable, but this is a very untenable solution because we would be either
• Changing core code
• Asking users to create custom ansible.cfg files every time they use BIG-IPs

233
F5 Ansible Documentation, Release 1.0.0

18.2 Proposals

What I propose is to provide the user with the ability to know what exists so that they can use the absent state of a
module to remove all existing instances. This will be done using a *_facts module for the manipulation module in
question.
Using the above example of bigip_snat_pool, the facts module would be bigip_snat_pool_facts. The user could
provide filtering params such as those they can supply to the bigip_snat_pool module to return only values that meet
those criteria.
The user can then store those returned values using a register variable and then loop over the values to delete them all
before adding new ones.
For example,

18.3 Future additions

Additionally, I would like to pursue the development of modules to support transactions such as
• bigip_transaction
This could be used to ensure that the above example is done in a way that would tolerate a failure between deleting
and re-creating SNAT pools. Thus, the replace-all-with functionality would essentially be retained.
For example,
Note the addition of Transactions above. This new functionality would be put into the f5_utils module_utils code
inside of Ansible to be supported across all modules.
For modules that do not support it, a @property would be defined to return only None.
For example,
This is similar in how the bigip_partition module always returns None for the partition parameter because you cannot
create partitions inside of partitions.
All properties should read from self._values[key]
All property.setters should write to self._values[key]
The ‘key’ in the self._values dictionary should match the API resource attribute. This allows us to easily determine

234 Chapter 18. Dealing with “replace all”

CHAPTER 19

Deprecating functionality

In a module, it may be necessary to raise warnings to the user due to deprecated functionality.
Normally, deprecations are done in the ArgumentSpec, such as when using the removed_in_version key shown below.
but that is only relevant when the parameter itself is deprecated. There are other deprecation scenarios for instance
where the parameter is a list of choices and the choices themselves are deprecated.
For example, consider the following parameter
One may need to deprecate the values themselves in favor of other values.
This may seem like a simple thing that one could add code to fix, but doing so would also lead to an increase in
technical debt. Having a mapping of old values to new values should be considered an anti-pattern and something that
is a candidate for deprecation.
To announce deprecations (for all things) you can use the removed_in_version field mentioned above, but you can also
have more customized deprecations raised by your module.
To do this, begin by amending the __init__ method of your Parameters class to define a __warnings variable.
Next, we need to add a new method to the ModuleManager, or, class specific manager (such as those used when
forking logic; ie, bigip_gtm_pool)
The definition of this method is the following
The third and final step is to actually make use of the deprecation code that you set up previously. Do do that, you
want to append to the aforementioned __warnings field.
An example is show below.

235
F5 Ansible Documentation, Release 1.0.0

236 Chapter 19. Deprecating functionality

CHAPTER 20

pycodestyle

Your modules should be flake free flake8

Your modules should conform to ansible’s validate-modules code

237
F5 Ansible Documentation, Release 1.0.0

238 Chapter 20. pycodestyle

CHAPTER 21

Design Patterns

These patterns are intended to

• make your time spent developing new modules shorter
• allow you to not need to decide “what to do”
• allow for easier unit testing
• allow for customizing the modules to meet edge cases easier
• allow for customizing the modules to meet feature requests easier
• allow for customizing the modules to address bug reports easier
If these patterns conflict with the above goals, the patterns should be re-evaluated and all modules should be changed
to support the new patterns.

21.1 CRUDable

• bigip_static_route

21.2 Only Updatable

• bigip_snmp

21.3 Executable

• bigip_command

239
F5 Ansible Documentation, Release 1.0.0

21.4 CRUDable Reference

iworkflow_tenant_connector

21.5 List item as member

• bigip_remote_syslog

240 Chapter 21. Design Patterns

CHAPTER 22

Class variables

The following class variables are common attributes that each Parameters class needs to define.

22.1 updatables

Specifies a list of Parameters properties to that are considered updatable by the module. This is used when doing
should_update()‘ comparisons and setting properties in self.changes.

22.2 api_attributes

Specifies a list Parameters properties to provide to the api_params()‘ method when generating valid sets of attributes
for resources in the REST API.
You will likely need to write adapter methods that call the properties used internally by the module when writing these.
For example
The reason that we use this method instead of the map method is because there may be cases where the value used in
api_params() is not a single property but a set of properties that need to be combined.
This is used by the api_params method to generate a valid set of attributes to provide to the REST API. Typically this
dictionary does NOT provide the name and partition parameters. These values should be specified specifically in the
(create|update|delete)_on_device methods

22.3 returnables

Specifies a list of Parameters properties for the to_return() method to iterate over when supplying
“changed” options back to the user

241
F5 Ansible Documentation, Release 1.0.0

22.4 api_map

We need to have a dictionary or a list of some stuff because there are times when the API parameters can not be written
as methods. For example, the bigip_device_dns APIs parameters include
This attribute is mapped to forwarders in the Ansible module.
The pattern that I had been developing is to use methods decorated as properties in python and then to call those
methods when setting values and getting values.
For example, the “dns.proxy.__iter__” API attribute would be mapped to the _values key “forwarders”. Normally I
would set the set the API attributes directly in the dictionary. I would need to get those API specific keys however
when I am returning the values to compare. this makes the getters for the Module options look messy though.
Next I thought about having the API attributes have their own @property decorators, but this won’t work in the “dns”
case mention above.
NEED a pattern for a single Ansible Option Parameter that returns 2 API attributes. For example in the
bigip_virtual_server module there is an option called enabled vlans. This, however, actually sets two (possibly 3)
values in the API
• vlans (list
• vlansDisabled (boolean True)
• vlansEnabled (boolean True)
what is a pattern that, that supports that?
The pattern is that the api_attributes is an arbitrary list of attributes that you want to send to the API.
The api_params() method uses this list to iterate over the
param_api_map does not work for situations where the Ansible->API relationship is 1->n (bigip_virtual_server with
enabled_vlans) param_api_map only works for 1->1
Requirements
• easy attribute comparison in Ansible parameters format with BIG-IP API values
• ability to consume API attributes that cannot be written as python functions (dns.proxy.__iter__ for exam-
ple)
params_spec=dict(
cache=’dns.cache’, forwarders=’dns.proxy.__iter__’, name_servers=’nameServers’,
search=’search’, ip_version=’include’
)
updatables = [ ‘cache’, ‘forwarders’, ‘name_servers’, ‘search’, ‘ip_version’
]
)

242 Chapter 22. Class variables

CHAPTER 23

Common classes

Nearly every module (see exceptions) should have the following classes. These classes are used to support the stated
design patterns.
• Parameters
• ModuleManager
• ArgumentSpec

23.1 Exceptions to common classes

Exceptions to the above rules will happen when,

• the API that a particular module addresses, changes underneath it between versions of the software.
• the resources or collections that the module is manipulating become too numerous
Good examples of this include
• bigip_ssl_certificate
• bigip_gtm_wide_ip

243
F5 Ansible Documentation, Release 1.0.0

244 Chapter 23. Common classes

CHAPTER 24

Defaulting to None

It should be noted that you should never specify default values in your ArgumentSpec. For example, the following is
incorrect
But, shouldn’t you be using the actual defaults?
Answer: No
The reason that you provide no defaults is to support cases where the user does not specify a value for a particular
option. If that happens, then you should not step on that parameter if it is preconfigured.
If a user had a setting that they want to keep and you specified a default value, then in the first opportunity that they
forgot to specify that value, you would end up replacing that value with your default.
This is a bad idea.
Ansible defaults required to False and default to None. Therefore, there is no need to specify these default values.

245
F5 Ansible Documentation, Release 1.0.0

246 Chapter 24. Defaulting to None

CHAPTER 25

What is the layer of @property decorators all about?

The ‘‘@property‘ decorators you see represent an adapter pattern. Inside of the ModuleManager, when data needs to
be compared (what you have vs what you want), that data is returned by these properties in a known format.
The API’s resource attributes differ in structure and name from the options that a user can provide to a module.
For example, an API resource may have an attribute called minSupportedBIGIPVersion. The user facing portion of the
module though, may refer to this attribute as min_bigip_version. There are a number of reasons to do this.
• it provides an abstraction of the API so the name of the thing being modified is not closely tied to the imple-
mentation of the API.
• many times the API attribute names are vague, this abstraction makes them more clear
• the Resource Attributes use camelCase variable naming, while some of python and nearly all of Ansible use
snake_case variable naming.
For future developer clarity’s sake, all of the attributes that we are interested in are typically compared by the option
name that they would have in Ansible and not the Resource attribute name.
This allows a developer to look at the names of variables and match them to the names of the options in the Ansible
module.
While the names of properties usually mirror the names of the module options available to the user, the values of those
properties do not.
Values of the properties reflect the values that are accepted by the API resource. This is done because, ultimately, the
values that we need to deal with at the values that are going to be used to update the API.
Therefore, when we receive options from the module, we transform them into the values that would appropriate for
the API. When we receive values from the API, we might order them or cast some of their values to specific types so
that comparisons can occur, but otherwise we dont really touch them.
So,
1. property name reflects module option
2. property getter reflects the appropriate Resource attribute value

247
F5 Ansible Documentation, Release 1.0.0

248 Chapter 25. What is the layer of @property decorators all about?
CHAPTER 26

Why are they not all setters?

This is because there are some cases where you do not know ahead of time what the value of that property should be.
Often it takes two or more options be set before another option can be known.
Consider a module that accepts an IP address option and a gateway mask option, but needs to return a CIDR represen-
tation of those two values. Without getting both values, we cannot produce the one value. That is who we calculate
the necessary value at time of getattr, and not at the time of setattr.

249
F5 Ansible Documentation, Release 1.0.0

250 Chapter 26. Why are they not all setters?

CHAPTER 27

Use the module_utils test suite to verify AnsibleF5Parameters classes

This is important in case there is a pattern we miss for adapting API attributes and module params.
This test suite is found at the following location
test/misc/test_module_utils.py

251
F5 Ansible Documentation, Release 1.0.0

252 Chapter 27. Use the module_utils test suite to verify AnsibleF5Parameters classes
CHAPTER 28

Never import *

9 times out of 10 you are doing this because you are using one of the following variables
• BOOLEANS
• BOOLEANS_TRUE
• BOOLEANS_FALSE
It is, however, an anti-pattern to import from * and it will be caught by the Ansible unit tests. Instead, specifically
include each thing that you want to use.

253
F5 Ansible Documentation, Release 1.0.0

254 Chapter 28. Never import *

CHAPTER 29

The Changes class

In many cases, the values that you process from the user will match the values that you send to BIG-IP.
For example, consider the following parameters to a module
Above, the module code that implements this is a collection of different adapters that collectively allow the module to
convert the information the user provides to it into a format that it is able to send to the BIG-IP and vice-versa.
This class is a way for the module developer to complete the cycle of
User (params) -> Module -> REST -> Module -> User (changed params)
Due to most of the adapters being concerned with how they should be adapting data to meet the format expect by the
REST API, the Changes class is concerned with how to adapt the data to meet the format expected by the end user.
If there is a need to change the value to something that is more “human” so that the user can understand it, that job is
undertaken by the Changes module.
An example of it in use is the bigip_device_connectivity module where it acts as a way to translate BIG-IP’s represen-
tation of “none” (any6) to the human word “none”
Examples of modules that use the Changes class are,
• bigip_gtm_datacenter
• bigip_device_connectivity
• bigip_device_group

255
F5 Ansible Documentation, Release 1.0.0

256 Chapter 29. The Changes class

CHAPTER 30

The Difference class

When comparing values to detect changed-ness, there are situations where the default comparison method will not be
appropriate for you use. The default comparison method essentially just does a simple comparison.
The source of this method illustrates its simplicity
As you can see, it is quite simple and does not take into consideration anything more complicated than simply the
values being compared.
This differencing is not conducive to more complicated data structures or types of data.
The above fails to satisfy this simple (albeit erroneous due to established patterns) difference.

Note: This is logically incorrect because the Adapter pattern that you should be using for the Parameters class
mandates that @property values should return a specific data type (in the above case int) and should never be non-
deterministic.

To check for differences in more complicated data structures, the module author should make use of the Difference
class.
The definition of the Difference class is the following
By default, it does nothing more than uses the simple comparison to diff the parameters provided, and discovered, by
the module.
To make use of it, you must do the following.
First, define this class in your module.
Second, add @property methods for each of the values that you want to compare. Remember, the properties of the
Parameter classes are the names that are exposed to the module user and not the names of REST API parameters
themselves (unless it perfectly matches) because the REST API camel-cases all parameter names.
So, if we were interested in providing custom diffing for the members module parameter, we may add this as a
@property to the Difference class like so.
These @property methods must be named after the Parameter you want to compare. Additionally, the return value of
these @property definitions is one of two values.

257
F5 Ansible Documentation, Release 1.0.0

• Python None if there is no difference

• The value of the difference if there is one. This value will later be reported as what was changed in the module
invocation.
Finally, to make use of this new difference class, you must change the following method in the ModuleManager code,
• _update_changed_options
The new value of this method must include the usage of the Difference class as a new object. Example usage is
provided below.

258 Chapter 30. The Difference class

CHAPTER 31

API Map Adapter

This adapter pattern is useful for converting data values from user inputs to REST outputs. It’s definition is,
The API Map Adapter pattern adapts a known REST attribute to a predefined Parameters method. The
return value of this method is a correct payload for the REST attribute.
This pattern is frequently used as a way for the module developer to translate the input provided to them by the user
into a format that is consumable by the REST API.
The following is an example of this kind of adapter.

259
F5 Ansible Documentation, Release 1.0.0

260 Chapter 31. API Map Adapter

CHAPTER 32

1-to-1 Adapter

YAML represents the banner parameter as a simple key with a simple value. The actual REST payload contains an
attribute called banner and it takes an actual value called enabled. This is represented in code by the ArgumentSpec
class.
This is considered to be the most simple form of a parameter definition by the F5 Ansible modules because it is nearly
a 1 to 1 translation of Ansible to F5.
The following is an example of this kind of adapter.

261
F5 Ansible Documentation, Release 1.0.0

262 Chapter 32. 1-to-1 Adapter

CHAPTER 33

Securing sensitive information

Parts of the f5-ansible repository contain information that is considered sensitive in nature, and therefore needs to have
a particular amount of due-diligence applied when handling it.
Information of that sort includes, but is not limited to,
• Product keys
• Internal URLs
• System configurations that are not relevant to the general public
To address the concerns of exposing this information in a plain-text manner, the authors have put in place a series of
GPG encrypted files. The remainder of this document explains how this system works.

33.1 Tools used

There are many existing tools that can help address the problem of storing secret information in an otherwise public
place. These include, but are not limited to,
• blackbox (from StackExchange)
• git-crypt
• git-secret
• Keyringer
• Pass
• Transcrypt
The tool that we use is blackbox primarily because
• It works in our docker containers
• It has a large number of stars and forks
• It is just shell wrappers around GPG

263
F5 Ansible Documentation, Release 1.0.0

• It automatically ignores files that have been registered

• StackExchange was a reason too
I won’t go into any philosophical arguments on the others, suffice it to say that blackbox does the job we needed to do.

33.2 Using it

To make use of the system, the first thing you must do is create a set of GPG keys to be used for encryption and
decryption of secrets.
Creating a key can be done with the gpg command. Consider the following example
This command will ask you a couple of questions related to your new keypair. They are,
• Real name
• Email address
For example,

root@9f1cc7b78557:~# gpg --gen-key

gpg (GnuPG) 2.1.20; Copyright (C) 2017 Free Software Foundation, Inc.
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

GnuPG needs to construct a user ID to identify your key.

Real name: Alice User

Email address: a.user@organization.com
You selected this USER-ID:
"Alice User <a.user@organization.com>"

Change (N)ame, (E)mail, or (O)kay/(Q)uit?

To proceed, answer O (the letter, not the number) and the command will proceed to ask you for a passphrase in a
separate window.

6------------------------------------^@
< Please enter the passphrase to |
< protect your new key |
< |
< Passphrase: ________________________________________ |
< |
< <OK> <Cancel> |
^@-----------------------------------5

If you do nothing else correctly for this procedure, you must absolutely get this step correct. Your passphrase is
considered hallowed ground. If Tim had his way, it would be a fire-able offense to disclose it. This is super important,
so listen.
Your passphrase is what is used to decrypt and encrypt sensitive data in the f5-ansible repository. If it is compromised,
then the information contained withing the gpg encrypted files is assumed to be compromised.
Now, because we include these gpg files in git, this also means that the compromised versions are accessible even if
we rotate the keys.
So it is your job to choose a passphrase (note I did not say pass**word**) that is sufficiently long to hedge the risk of
having it discovered computationally.

264 Chapter 33. Securing sensitive information

F5 Ansible Documentation, Release 1.0.0

How do you do that?

There is a practice referred to as Diceware that allows you to choose a passphrase that is sufficiently difficult to
computationally discover.
Diceware is elaborated on in much greater detail here
• http://world.std.com/~reinhold/diceware.html
In a nutshell, you toss a dice and record the number. Those numbers correspond to words in a word list.
It is recommended that the passphrase you create is at least six words and a symbol; in any order.

33.3 Don’t have a pair of dice to roll?

Then you have a problem.

If you do not have a pair of dice to roll to make your word list, the next best option is using an online service. There
are ones that allow you to roll digitally, as well as those that will generate word lists for you on the fly.
For example,
• https://www.rempe.us/diceware/#eff

33.4 Finishing up your key

Once you have a passphrase chosen, enter it in the aforementioned box. Pressing Enter will ask you to re-enter the
passphrase.

6------------------------------------^@
< Please re-enter this passphrase |
< |
< Passphrase: ________________________________________ |
< |
< <OK> <Cancel> |
^@-----------------------------------5

Pressing Enter after typing the passphrase a second time will generate the necessary public and private keys for you,
as well as add them to your GPG keychain locally on disk.
For example,

gpg: key 5FE19AB05871BDA3 marked as ultimately trusted

gpg: revocation certificate stored as '/gpg//openpgp-revocs.d/
˓→6CA2078812CBB7F6112BDADF5FE19AB05871BDA3.rev'

public and secret key created and signed.

pub rsa2048 2017-09-26 [SC] [expires: 2019-09-26]

6CA2078812CBB7F6112BDADF5FE19AB05871BDA3
6CA2078812CBB7F6112BDADF5FE19AB05871BDA3
uid Alice User <a.user@organization.com>
sub rsa2048 2017-09-26 [E] [expires: 2019-09-26]

root@9f1cc7b78557:~#

You can verify that your keys exist in your keyring with the following command

33.3. Don’t have a pair of dice to roll? 265

F5 Ansible Documentation, Release 1.0.0

gpg --list-keys

If you were successful, you will see your key in the list.

pub 2048R/5871BDA3 2017-09-26 [expires: 2019-09-26]

uid Alice User <a.user@organization.com>
sub 2048R/0B29438A 2017-09-26 [expires: 2019-09-26]

Note: Be aware that when you created your key, it was given an expiration date a couple years (two by default) in the
future. It is critical that you perform a key renewal as your key becomes due for expiration. Instructions for doing this
can be found here

33.5 Including your key in the test environment

With your keys generated, you can now include them in the Docker development containers that are provided with
f5-ansible.
In the devtools/docker-compose.yaml file in this repository is a config section that resembles the following

- type: bind
source: ~/.gnupg
target: /gpg

This configuration instructs docker-compose to create a path in your container (at runtime) that maps the .gnupg
directory in your home directory to the /gpg directory in the container.
If you need to change the location in which your GPG keys are found on your local filesystem, the recommended place
to change that is in the configuration above.

33.6 Encrypting files

Determining what you should and should not encrypt is the first step in this process.
Generally speaking we encrypt anything that is “F5 specific”. This is kind of vague though, so here are some examples,
• Websites that are internal to F5
• License keys used for integration tests
• Configuration of system that is irrelevant to the public (insofar as it would not help them in any way to have)
For all of those, and more, instances, we encrypt.
Adding new files to the encryption process starts with the following command

blackbox_register_new_file path/to/file.ext

Note: The suite of blackbox_ commands is your interface to the process of encryption and decryption. There are
many commands that one can use. The ones you are most likely to use are,
• blackbox_register_new_file
• blackbox_decrypt_all_files

266 Chapter 33. Securing sensitive information

F5 Ansible Documentation, Release 1.0.0

• blackbox_deregister_file
• blackbox_edit_start
• blackbox_edit_end
• blackbox_list_files

For a video demonstration of the above encryption process, refer to [go/f5ansible-video-6609](go/f5ansible-video-

6609)

33.6. Encrypting files 267

F5 Ansible Documentation, Release 1.0.0

268 Chapter 33. Securing sensitive information

CHAPTER 34

SSH functionality for modules

A requested feature of the F5 modules has been the ability to use SSH to configure them.
I looked into this possibility and after discussing with Michael about it, it was suggested that to retain the ability to
parse structured output (ie, the REST output) that we should try to use local curl commands to the same APIs and that
we would therefore get the same results which we could sent to our existing Parameter classes.
This sounded goo, but it has some deficiencies that a user needs to be aware of before they can make use of it.

34.1 Limited role usage

By far the largest limitation is that there are only two roles who are actually able to use the “Advanced shell” also
known as “bash”.
• Administrator
• Resource Administrator
All other roles are limited to the tmsh shell only. This results in two problems.
First, since you are in tmsh, you do not natively have a curl command that you can use. Normally you would be able
to use curl because it is installed and is a standard feature of the system. However, you do not have a curl command
that can be run from, for example tmsh run util...
This first problem can actually be worked around if you have one of the two roles mention above, associated with your
account.
If you have either role, you can make use of curl through the tmsh run util bash command.

34.2 Appliance mode

This restriction is where things get really hairy.

Appliance mode’s restrictions are outlined in this support article.

269
F5 Ansible Documentation, Release 1.0.0

• https://support.f5.com/csp/article/K12815
I will reiterate some of those restrictions below.
• Access to the Advanced shell (bash) has been removed.
• Administrative access is limited to the Configuration utility, bigpipe shell (bpsh), and Traffic Management Shell
(tmsh)
• The root user cannot log in to the device by any means, including the serial console.
• To disable Appliance mode, you must contact F5 for assistance in removing Appliance mode from your license
file and then perform a clean installation of the software.
The above restrictions essentially make it exceedingly difficult to configure the device using an API that provides
structured data. Additionally, it may make some actions that we take in the modules completely impossible such as
uploading file data which would appear to require SCP functionality in the case of Appliance Mode.
As it stands, the above requirements would mean that we would need to rely on tmsh itself to accomplish anything.
This means working with a tool that does not provide structured output; only free form output.
Indeed there is a –oneline argument that may be supplied to tmsh commands, but it is not clear to the author how
parseable, or reliable, this format is.

34.3 Conclusion

For the above reasons, if CLI functionality is pursued for any of these modules, it is my recommendation that the
functionality only be allowed for users who are of one of the following roles,
• Administrator
• Resource Administrator
Note that it is not required that the user of the modules need worry about which partitions they are allowed to access.
With these roles you can access all of them.
Without making this a requirement, it may not be possible to provide a user of the modules with a reliable way to
configure the system due to restrictions that are put in place by other roles.

270 Chapter 34. SSH functionality for modules

CHAPTER 35

Issue Management

When doing triage of new or existing Issues, please abide by the following conventions.
• If the issue seems to be, by your best judgement, a bug, add the label bug-report to it. This will assist F5’s
support organization in the care and feeding of the F5 modules.

271
F5 Ansible Documentation, Release 1.0.0

272 Chapter 35. Issue Management

CHAPTER 36

Pulling Docker Containers

If you are an F5’er, then you have access to an internal docker registry.
If you are reading this, then you should also know what that registry is. If not, then visit this link
These instructions are only relevant to you if you are an F5’er. If not, feel free to skip over this document.

36.1 How it works

At this registry there is an organization named f5ansible. There are several repositories in this organization. For
instance,
• f5ansible/py2.7
• f5ansible/py3.5
• f5ansible/py3.6
• etc
You get the idea.
Each of these images is, as their name implies, a different Docker environment for each version of Python that we
develop and test upon.
These containers are also named in the various image keys inside of the docker-compose file contained in this reposi-
tory. For example,

services:
py2.7:
image: f5ansible/py2.7:devel
build:
context: ..

All of the containers that you see are built nightly at midnight by a trigger that is fired when a Jenkins job completes.
That job is found in this jenkins-job-builder file.

273
F5 Ansible Documentation, Release 1.0.0

• test/pipeline/ci.f5.f5-ansible-public-to-private.yaml
Therefore, when you come in the next morning (assuming you work in Seattle) you will have a new set of docker
images available to you.

36.2 Configure registry authentication

The first step required to get these updated containers on a regular basis is that you must log in to the registry service
mentioned above and get a set of encrypted credentials that the service can provide you with.
Clicking the settings for your account (upper right corner of the registry) you will be presented with the option of a
CLI password.
Click the associated link and you will be asked to verify your current password. Enter it as required.
In the modal dialog window that appears you have the option of choosing Docker Configuration. Click that tab.
Follow the instructions on screen to properly configure your ~/.docker/config.json file.

36.3 Updating the site docker-compose

F5 has its own registry for containers. To configure your docker-compose files to use it, start by locating the following
file
• devtools/docker-compose.site.example.yaml
Next, copy this file, renaming it to the following.
• devtools/docker-compose.site.yaml
Finally, open the file for editing. Inside of the file is a descriptive header that will instruct you on how to edit the file.
In particular, you need to add the URL of the F5 Docker registry. If you do not know what this is, ask a co-worker for
assistance.

36.4 Getting the images

With the above setup and configured, you can pull the images using the docker-compose command. For example,

SEA-ML-00028116:f5-ansible trupp$ ./devtools/bin/f5ansible container-pull

This should initiate a download of the necessary containers.

274 Chapter 36. Pulling Docker Containers

CHAPTER 37

Allow new admin access of private data

In this tutorial I will outline the steps you need to take to add a new person to the list of allowed admins for handling
the encrypted data in this repository.

37.1 When should I do this?

You should do this whenever you have deemed it necessary that a new person should be assigned to handle secure
information.
Our policy is that the developers responsible for this software will be granted access to this repository.
Additionally, there may be an unspecified number of robot services that have subkeys registered in the list of admins.
These keys have no business editing the content of the admin file. They must still be able to decrypt the content of the
entire repository as needed to do their job; run CI/CD testing and deployment.

37.2 Who should do this?

This is a two step process that involves the following people

1. The person who wants to be added
2. The person who needs to do the adding
The process goes something like this
1. Admin chooses a new primary or secondary
2. Chosen person agrees and adds their public key in a PR
3. Admin merges this PR
4. Admin rebases their code to get the upstream changes
5. Admin imports the public keyring into their local keyring

275
F5 Ansible Documentation, Release 1.0.0

6. Admin re-encrypts all the files and pushes those changes

As you can see, the admin will be doing most of the work, but that work largely needs to be initiated by the user in the
form of them adding their public key in a PR.
Let’s look now at how to do that.

37.3 How do I do this?

All of the work can be done inside of the development containers that are available in the ./devtools/bin directory. In
this example I will use the run-py2.7 script to launch the relevant container.
We are going to begin with the person who wants to be added.

37.4 Creating a keypair

To perform these steps, start by firing up the py2.7 (or equivalent) container.

SEA-ML-RUPP1:f5-ansible trupp$ ./devtools/bin/run-py2.7

Within this container, use the gpg2 –gen-key command to create the keypair you will use. An example is shown below.

root@d7f809815281:/here# gpg2 --gen-key

gpg (GnuPG) 2.1.20; Copyright (C) 2017 Free Software Foundation, Inc.
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

Note: Use "gpg2 --full-generate-key" for a full featured key generation dialog.

GnuPG needs to construct a user ID to identify your key.

Real name: Foo Bar

Email address: foo.bar@f5.com
You selected this USER-ID:
"Foo Bar <foo.bar@f5.com>"

Change (N)ame, (E)mail, or (O)kay/(Q)uit? O

gpg: key DBB462DE79ADE8C9 marked as ultimately trusted

gpg: directory '/gpg/openpgp-revocs.d' created
gpg: revocation certificate stored as '/gpg/openpgp-revocs.d/80E......................
˓→............8C9.rev'

public and secret key created and signed.

pub rsa2048 2017-10-11 [SC] [expires: 2019-10-11]

80E..................................8C9
80E..................................8C9
uid Foo Bar <foo.bar@f5.com>
sub rsa2048 2017-10-11 [E] [expires: 2019-10-11]

root@d7f809815281:/here#

With this complete, you should see your email address when using the gpg2 –list-keys command.

276 Chapter 37. Allow new admin access of private data

F5 Ansible Documentation, Release 1.0.0

37.5 For the person who wants to be added

We assume that you have created an initial keypair to use for encryption. If you have not yet done that, follow the
instructions below in the (Creating a keypair)[] section.
Begin by starting that container with the necessary script

SEA-ML-RUPP1:f5-ansible trupp$ ./devtools/bin/run-py2.7

This command will leave you at a new shell prompt. Within this new prompt, the next step is to create a new branch
which will contain the pull request with your admin addition in it. This can be done with git

SEA-ML-RUPP1:f5-ansible trupp$ git checkout -b add-admin upstream/devel

git should notify you that you have changed branches.

Next you will run the blackbox_addadmin command to change the necessary files for adding you as an admin. The
single argument to this command is the email address that you specified when you created your initial key pair.

blackbox_addadmin foo.bar@f5.com

When this command finishes, there will be several new files which are shown as modified. Additionally, the black-
box_addadmin command will instruct you on the command you need to use to commit these changes.

root@d7f809815281:/here# blackbox_addadmin foo.bar@f5.com

gpg: key DBB462DE79ADE8C9: public key "Foo Bar <foo.bar@f5.com>" imported
gpg: Total number processed: 1
gpg: imported: 1

NEXT STEP: You need to manually check these in:

git commit -m'NEW ADMIN: foo.bar@f5.com' keyrings/live/pubring.kbx keyrings/
˓→live/trustdb.gpg keyrings/live/blackbox-admins.txt

root@d7f809815281:/here#

A git status command will also illustrate this.

root@d7f809815281:/here# git status | grep keyrings

modified: keyrings/live/blackbox-admins.txt
modified: keyrings/live/pubring.kbx
root@d7f809815281:/here#

Do as the instructions say above and commit those files

git commit -m'NEW ADMIN: foo.bar@f5.com' keyrings/live/pubring.kbx keyrings/live/

˓→trustdb.gpg keyrings/live/blackbox-admins.txt

You may now push the PR to the Github repository and follow the normal PR process.

37.6 For the existing admin doing the adding

First, verify and merge the PR sent by the user wishing to be added.

Note: Adding a new user to the public key chain in the steps above is not, immediately, a security risk. This is because
you have not yet re-encrypted the files. If you mistakenly merge a PR from a bad actor, you should immediately reverse

37.5. For the person who wants to be added 277

F5 Ansible Documentation, Release 1.0.0

this merge by using the blackbox_removeadmin command.

If you have already re-encrypted all of the files with this new key, then you still have the ability to undo your mistake
by re-checking out the modified *.gpg files.
If you have committed those files, you have one last chance to save yourself by undoing the merge in question before
you push your changes to the upstream repository.
If you have failed to catch yourself at the numerous places above, your only remaining option is to either re-write
history (bad idea) or legitimately remove the bad key, change all secrets, and re-encrypt as normal.

Next, merge the aforementioned PR into the repository. After that, you will want to rebase your own fork of the code
to include this new merge commit

git fetch upstream

git stash
git rebase upstream/devel
git stash apply

The above follows a simple set of steps where-by we

• Get any changes from the upstream source code (which would include the PR that the user who wanted to be
added just made)
• Stash any changes that we may have been working on. This prevents the next step from failing.
• Rebase the upstream code-base onto your current code-base. This will allow the new user’s PR to land in your
local source tree.
• Re-apply the code that you previously stashed away. This will put you back to where you left off.
With the new changes in your source tree, it’s time that you re-encrypted all of the private files with the new users
public key. To do that, you can use the blackbox_update_all_files command from inside of any of the development
containers.

root@a710b12b1e97:/here# blackbox_update_all_files
========== blackbox administrators are:
caphrim007@gmail.com
HypePDSvc
k.austria@f5.com
========== Importing keychain: START
gpg: key DBE7B40B4ACC6C92: public key "Kat Austria <k.austria@f5.com>" imported
gpg: Total number processed: 10
gpg: imported: 1
gpg: unchanged: 9
========== Importing keychain: DONE
========== ENCRYPTED FILES TO BE RE-ENCRYPTED:
devtools/secrets/jenkins_jobs.ini.secret.gpg
...
test/runner/roles/harness/vars/TwoArmed-bigiq-5.3.0.yaml.gpg
test/runner/roles/harness/vars/TwoArmed-iworkflow-2.1.0.yaml.gpg
========== FILES IN THE WAY:
devtools/secrets/jenkins_jobs.ini.secret
test/heat/jenkins-secondary-params.yaml
test/pipeline/ci.f5.f5-ansible-public-to-private-parameters.include.yaml
test/runner/roles/harness/vars/TwoArmed-bigip-12.1.2-hf1.yaml

WARNING: This will overwrite any unencrypted files laying about.

Press CTRL-C now to stop. ENTER to continue:

278 Chapter 37. Allow new admin access of private data

F5 Ansible Documentation, Release 1.0.0

Press ENTER to proceed and re-encrypt all of the secrets. You will be asked for your own encryption password in the
process.

...
========== RE-ENCRYPTING FILES:
========== PROCESSING "devtools/secrets/jenkins_jobs.ini.secret"
========== Encrypting: devtools/secrets/jenkins_jobs.ini.secret
========== Encrypting: DONE
...
========== PROCESSING "test/runner/roles/harness/vars/TwoArmed-iworkflow-2.1.0.yaml"
========== EXTRACTED test/runner/roles/harness/vars/TwoArmed-iworkflow-2.1.0.yaml
========== Encrypting: test/runner/roles/harness/vars/TwoArmed-iworkflow-2.1.0.yaml
========== Encrypting: DONE
========== COMMITING TO VCS:
[devel f7021f1] Re-encrypted keys
35 files changed, 49 insertions(+)
rewrite devtools/secrets/jenkins_jobs.ini.secret.gpg (100%)
...
rewrite test/runner/roles/harness/vars/TwoArmed-bigiq-5.3.0.yaml.gpg (100%)
rewrite test/runner/roles/harness/vars/TwoArmed-iworkflow-2.1.0.yaml.gpg (100%)
========== DONE.
Likely next step:
git push

blackbox will end with telling you what the likely next step is; git push. Indeed, if you view the git log, you can see
there is a new commit there for the re-encryption process.

commit f7021f14193d7d81f22920c2dbe0f16d90f08f17
Author: Tim Rupp <caphrim007@gmail.com>
Date: Tue Nov 7 00:30:07 2017 +0000

Re-encrypted keys

Therefore, do the push as requested. Once this is done, the new maintainer will have the ability to decrypt the secrets.

37.6. For the existing admin doing the adding 279

F5 Ansible Documentation, Release 1.0.0

280 Chapter 37. Allow new admin access of private data

CHAPTER 38

Parameter classes

The modules make use of a Parameter class that acts as a rudimentary two-way adapter. This class adapts data in the
following ways,
• Ansible module parameters submitted by the user into REST API attributes
• REST API attributes into Ansible module parameters for comparison and internal data structures.
This method has served most modules well, for a number of modules though, the abstraction has been difficult to work
with. This largely stems from instances where,
• The api_map maps resource attribute names to Ansible module parameter names which are similarly named but
have wildly different values
• When a name conflict results in not knowing “how to best” determine if you are dealing with the API’s values
or the Module’s values. We have side-stepped this problem in certain situations by checking for the existence of
the kind key and comparing it to what we know to be the _real_ kind key for the resource
• We need to include resource attributes in the updatables key because there is no other way to get them into the
api_params method. The error is doing this even if that updatables addition is not an Ansible module parameter.
The updatables list is intended to be a list of only Ansible module parameter names.
• It has been difficult to do Difference engine comparisons if the values that need to be compared (API values) are
not in the updatables array because only those values are diff’d.
In an attempt to settle the difficulty of using the “big adapter”, as I lovingly call it, a different pattern is being tested
where different classes (inheriting from a Parameters base class) will be used for the Ansible module parameters
(ModuleParameters) and the REST API parameters (ApiParameters).
Additionally, the base Parameters class will be changing its base definition to remove the __getattr__ definition that
it has. This definition has introduced an added layer of difficulty when debugging problems because it implicitly
swallows and errors that may be raised by invalid “dot” attribute access. For example, self.want.baz where exceptions
raised in baz may be swallowed. The only indication that this has happened is that a post q.q call will never happen.
For example,

...
q.q("started here")

281
F5 Ansible Documentation, Release 1.0.0

self.want.baz # <-- raises exception internally

q.q("ended here")

In the above (when the situation that I described above happens) the second q.q call will never happen. There will be
no entry in the q log file location, but success of the module may actually happen! This is a can of worms, so we need
to eliminate it before we regret it.
The base Parameters class will also have it’s signature changed from,

def init(self, params=None):

to a version that allows for a free-form of parameters and selectively chooses “special” parameters to do key things
with. The new signature is,

def init(self, *args, **kwargs):

This allows us to expand on what the “valid” kwargs to the init method are. To begin with, there are two args that the
base Parameters classes will know about. They are,
• params
• client
The former is no different than the way things work today; the exception being that you will need to be explicit when
supplies params to a Parameters derived class because params is no longer just assumed to be the default. To change
you code, would require the following be done,

# legacy version
self.want = Parameters(self.client.module.params)

be changed to

# current version
self.want = ModuleParameters(params=self.client.module.params)

The later client parameter is new to the Parameters base class. In existing code bases it is possible to add this
functionality to your concrete Parameter classes, but it is not obvious how, nor well-documented.
For example, today the following would need to be accomplished,

self.want = Parameters()
self.want.client = self.client
self.want.update(self.client.module.params)

This will be able to be changed to the following,

self.want = ModuleParameters(
client=self.client,
params=self.client.module.params
)

Any concrete params class that inherits from the Parameters base class will be able to use the method show above.
The client= feature seems like it was added only to make the above easier and more explicit. That, however, was more
an unintended consequence than a goal. The real purpose for doing the above was for the following
• BIG-IQ
• Unit tests (for BIG-IQ)

282 Chapter 38. Parameter classes

F5 Ansible Documentation, Release 1.0.0

Note: My assumptions here are based on the work that others have done in this area. When I wrote this, I did not
have first-hand experience with BIG-IQ; only the iWorkflow codebase (which was originally a fork of BIG-IQ).

You see, the BIG-IQ code-base will require situations where the concrete Parameters classes themselves will be
responsible for reading data from the remote device.
This is because, in many circumstances, we cannot know all of the resources and their attributes that we need to deal
without, without querying for data using a resource attribute itself as input.
Surprisingly, we know this is going to be a problem, because we’ve already experienced it. Where? In iWorkflow.
You see, iWorkflow’s REST API was created from a fork (long ago in a galaxy far far away) of an older BIG-IQ
code base. Many of the similarities have disappeared over time, but the one thing that has remained constant is that
BIG-IQ’s API is one where you have to do a HUGE amount of “extra” work to just do what you need to do.
That means that concrete Parameters will need to do this work so that the user does not need to. For example, you’re
setting yourself up for failure if you plan on using Postman to work with your BIG-IQ. Good luck with that. The
Ansible modules deliberately provide a layer of “niceness” that you simply do not get with direct API communication.
But that’s A-OK, because all that direct API stuff and what concrete class needs to have a client really all boils down
to “implementation details”. The developers (you because you’re reading this) need to worry about it; the users do not.

283

Bigip Update Upgrade Guide
No ratings yet
Bigip Update Upgrade Guide
85 pages
Route Leaking in MPLS/VPN Networks: Document ID: 47807
No ratings yet
Route Leaking in MPLS/VPN Networks: Document ID: 47807
5 pages
f5 Tmos Operations Guide
100% (2)
f5 Tmos Operations Guide
273 pages
F5 Troubleshooting Guide
No ratings yet
F5 Troubleshooting Guide
35 pages
f5 Problem
100% (2)
f5 Problem
58 pages
2.01 - Identify General Meanings of HTTP Error Codes
No ratings yet
2.01 - Identify General Meanings of HTTP Error Codes
20 pages
Troubleshooting 54 PDF
No ratings yet
Troubleshooting 54 PDF
79 pages
F5 201 - Study Guide - TMOS Administration r2
No ratings yet
F5 201 - Study Guide - TMOS Administration r2
108 pages
LTM Ess WBT LabGuide v11 091213
No ratings yet
LTM Ess WBT LabGuide v11 091213
104 pages
Big-Ip Systems: Getting Started Guide
No ratings yet
Big-Ip Systems: Getting Started Guide
96 pages
F5 LTM Troubleshooting Guide
No ratings yet
F5 LTM Troubleshooting Guide
15 pages
3.1 Accessing The EOS CLI
No ratings yet
3.1 Accessing The EOS CLI
82 pages
Tcpdump Packet Tracing Guide
No ratings yet
Tcpdump Packet Tracing Guide
7 pages
Irule CONFIGUR
No ratings yet
Irule CONFIGUR
10 pages
F5 BIG-IP LTM Configuration Guide
67% (3)
F5 BIG-IP LTM Configuration Guide
7 pages
F5 ASM Training
No ratings yet
F5 ASM Training
3 pages
F5 BIG-IP APM - Implementation Guide
No ratings yet
F5 BIG-IP APM - Implementation Guide
8 pages
Cisco ASA Troubleshooting Guide
No ratings yet
Cisco ASA Troubleshooting Guide
33 pages
Untitled
No ratings yet
Untitled
730 pages
F5 Exam Prep: Key Concepts
No ratings yet
F5 Exam Prep: Key Concepts
66 pages
Charles Media Cisco Ip Routing Protocols Troubleshooting Techniques 2004
100% (1)
Charles Media Cisco Ip Routing Protocols Troubleshooting Techniques 2004
362 pages
BIG IP Reference
No ratings yet
BIG IP Reference
504 pages
SRX HA Deployment Guide
No ratings yet
SRX HA Deployment Guide
35 pages
Checkpoint R65 QoS Admin Guide
No ratings yet
Checkpoint R65 QoS Admin Guide
220 pages
Palo Alto Networks and Ansible
No ratings yet
Palo Alto Networks and Ansible
4 pages
Big Ip
No ratings yet
Big Ip
48 pages
CEH v10 Module 01 Introduction To Ethical Hacking
100% (1)
CEH v10 Module 01 Introduction To Ethical Hacking
45 pages
F5 Big-IP LTM v10 Advanced Topics - Student Guide
75% (4)
F5 Big-IP LTM v10 Advanced Topics - Student Guide
289 pages
Monitoring BIG-IP System Traffic With SNMP
No ratings yet
Monitoring BIG-IP System Traffic With SNMP
41 pages
Cisco XR Routing
No ratings yet
Cisco XR Routing
604 pages
CP R80.10 Gaia Advanced Routing AdminGuide
100% (1)
CP R80.10 Gaia Advanced Routing AdminGuide
232 pages
F5 LTM Cisco ISE PDF
100% (1)
F5 LTM Cisco ISE PDF
115 pages
Understanding NAT 4.1 RevC
No ratings yet
Understanding NAT 4.1 RevC
30 pages
Application Delivery Fundamentals: F5 101 Version Demo
No ratings yet
Application Delivery Fundamentals: F5 101 Version Demo
12 pages
F5 - Getting Started Lab Introduction
0% (1)
F5 - Getting Started Lab Introduction
15 pages
Configuring BIG IP ASM ApplicationSecurityManager1
No ratings yet
Configuring BIG IP ASM ApplicationSecurityManager1
7 pages
F5 BIG-IP LTM Lab Guide
No ratings yet
F5 BIG-IP LTM Lab Guide
81 pages
F5 Virtual Server Troubleshooting Guide
No ratings yet
F5 Virtual Server Troubleshooting Guide
31 pages
NIOS 8.6.x Documentation
No ratings yet
NIOS 8.6.x Documentation
2,330 pages
ACI F5 Integration
No ratings yet
ACI F5 Integration
49 pages
BIG-IP System IRules Concepts
No ratings yet
BIG-IP System IRules Concepts
44 pages
ASR9000 Upgrade Procedure 431 PDF
No ratings yet
ASR9000 Upgrade Procedure 431 PDF
12 pages
BIG-IP Link Controller Implementations
No ratings yet
BIG-IP Link Controller Implementations
80 pages
CP R80 SecurityManagement AdminGuide
100% (1)
CP R80 SecurityManagement AdminGuide
172 pages
BIG-IP Automation 202108 LK
No ratings yet
BIG-IP Automation 202108 LK
101 pages
Notes 1
No ratings yet
Notes 1
1 page
Data Center Interconnect
No ratings yet
Data Center Interconnect
70 pages
F5-101 - 29 May 2020
No ratings yet
F5-101 - 29 May 2020
157 pages
SRX Troubleshooting Guide
100% (2)
SRX Troubleshooting Guide
53 pages
Ansible f5 PDF
No ratings yet
Ansible f5 PDF
86 pages
Ansible for Network Engineers
100% (1)
Ansible for Network Engineers
23 pages
F5 Ansible Automation Guide
No ratings yet
F5 Ansible Automation Guide
34 pages
Ansible F5 Deck PDF
No ratings yet
Ansible F5 Deck PDF
79 pages
Ansible Training Guide: AWS to Deployment
No ratings yet
Ansible Training Guide: AWS to Deployment
27 pages
Ansible Notes
No ratings yet
Ansible Notes
25 pages
Automate BIG-IP with iControl & Ansible
No ratings yet
Automate BIG-IP with iControl & Ansible
3 pages
Learning Ansible 2 2nd Edition Fabio Alessandro Locati 2024 Scribd Download
100% (9)
Learning Ansible 2 2nd Edition Fabio Alessandro Locati 2024 Scribd Download
55 pages
Ansible Junos Evpn Vxlan
No ratings yet
Ansible Junos Evpn Vxlan
19 pages
Ansible Master
No ratings yet
Ansible Master
11 pages
Ansible From Basics To Network Automation
No ratings yet
Ansible From Basics To Network Automation
34 pages
CIS Google Chrome Benchmark v1.3.0
No ratings yet
CIS Google Chrome Benchmark v1.3.0
52 pages
Kubernetes Tasks Documentation: Release 0.1
No ratings yet
Kubernetes Tasks Documentation: Release 0.1
51 pages
CIS Amazon Elastic Kubernetes Service (EKS) Benchmark v1.0.0
No ratings yet
CIS Amazon Elastic Kubernetes Service (EKS) Benchmark v1.0.0
135 pages
Kubernetes Command Reference
No ratings yet
Kubernetes Command Reference
1 page
CIS Alibaba Cloud Foundation Benchmark v1.0.0
No ratings yet
CIS Alibaba Cloud Foundation Benchmark v1.0.0
205 pages
GKE Security Benchmark Guide
No ratings yet
GKE Security Benchmark Guide
388 pages
Automation With Ansible
0% (1)
Automation With Ansible
4 pages
Automation With Ansible
0% (1)
Automation With Ansible
4 pages
CIS Kubernetes Benchmark v1.3.0 PDF
No ratings yet
CIS Kubernetes Benchmark v1.3.0 PDF
250 pages
Ansible Training & Deployment Guide
100% (1)
Ansible Training & Deployment Guide
116 pages
Administrator 6.5 SP3 User Guide
No ratings yet
Administrator 6.5 SP3 User Guide
797 pages
h8174 Migrating Celerra VNX Replicator WP
No ratings yet
h8174 Migrating Celerra VNX Replicator WP
87 pages
SynchronousMirroring AAG MR
No ratings yet
SynchronousMirroring AAG MR
1 page
Cross Platform Transportable Tablespaces Migration in Oracle 11g - ViSolve Inc
No ratings yet
Cross Platform Transportable Tablespaces Migration in Oracle 11g - ViSolve Inc
33 pages
3PAR Online Import For EMC - Migration
No ratings yet
3PAR Online Import For EMC - Migration
19 pages
Plugin-CIS Apache Tomcat Benchmark v1.0.0
No ratings yet
Plugin-CIS Apache Tomcat Benchmark v1.0.0
56 pages
Ax 2012 R 3 Installation Guide
100% (1)
Ax 2012 R 3 Installation Guide
240 pages
Powerfactory 2021: Advanced Installation and Configuration Manual
No ratings yet
Powerfactory 2021: Advanced Installation and Configuration Manual
97 pages
9153 OMC-R Getting Started
No ratings yet
9153 OMC-R Getting Started
116 pages
Basic It & Cyber Security Awareness Training
No ratings yet
Basic It & Cyber Security Awareness Training
31 pages
Xanadu It Operations Management Itom Health 2024-11-22-08-36-50
No ratings yet
Xanadu It Operations Management Itom Health 2024-11-22-08-36-50
4 pages
Windows Server Admin Resume
No ratings yet
Windows Server Admin Resume
2 pages
Modified Thomas Seeker Resume TXT v2
No ratings yet
Modified Thomas Seeker Resume TXT v2
2 pages
LogRhythm Software Install Guide 7.4.8 RevA
No ratings yet
LogRhythm Software Install Guide 7.4.8 RevA
123 pages
Ashishparikh Resume
No ratings yet
Ashishparikh Resume
2 pages
EPA GPP Criteria ICT 2022 04
No ratings yet
EPA GPP Criteria ICT 2022 04
94 pages
Project Planning Guide
No ratings yet
Project Planning Guide
16 pages
R7.1 DeployingAADS
No ratings yet
R7.1 DeployingAADS
197 pages
Java LAN Chat App Guide
73% (11)
Java LAN Chat App Guide
13 pages
01 HCNA-Cloud V2.0 Lab Guide
No ratings yet
01 HCNA-Cloud V2.0 Lab Guide
179 pages
5.3 IBM General Parallel File System: 5.3.1 Common GPFS Features
No ratings yet
5.3 IBM General Parallel File System: 5.3.1 Common GPFS Features
12 pages
XMC 8.5 Technical Reference Guide
No ratings yet
XMC 8.5 Technical Reference Guide
32 pages
IT Infrastructure Specialist Resume
No ratings yet
IT Infrastructure Specialist Resume
5 pages
MC - Press Iseries - And.as.400.java - At.work - CHM
No ratings yet
MC - Press Iseries - And.as.400.java - At.work - CHM
656 pages
Boopathy Netapp Storage LAB
No ratings yet
Boopathy Netapp Storage LAB
17 pages
NetBackup105 Commands
No ratings yet
NetBackup105 Commands
1,094 pages
Client-Server Architecture Guide
No ratings yet
Client-Server Architecture Guide
11 pages
Solidworks PDM - BiteSize Series
No ratings yet
Solidworks PDM - BiteSize Series
19 pages
NBU Walk Through Document
No ratings yet
NBU Walk Through Document
59 pages
Change Management Training
No ratings yet
Change Management Training
86 pages
Exame HP Proliant Server Foundation
100% (2)
Exame HP Proliant Server Foundation
13 pages
Double Take Availability Windows & Linux.
No ratings yet
Double Take Availability Windows & Linux.
73 pages
Cisco SNS 3415 Hardware Guide
No ratings yet
Cisco SNS 3415 Hardware Guide
8 pages
Installing VSCode Server On Remote Machine in Private Network (Offline Installation) - by Rahul Kumar - Medium
No ratings yet
Installing VSCode Server On Remote Machine in Private Network (Offline Installation) - by Rahul Kumar - Medium
8 pages
Introduction To System Administration
No ratings yet
Introduction To System Administration
3 pages
SY Minor Project Design Report Template 2024 2025
No ratings yet
SY Minor Project Design Report Template 2024 2025
59 pages