The modules listed in this PR were using YAML that resulted in
blockquote tages being inserted into the generated RestructedText.
This PR fixes that so that the documentation once again looks correct
This argument had a couple of issues with it. First, as it was
being interpreted in the code, it did not check for idempotency.
Second, the model of having the parameters be "all_*" is going to
hinder the ability to "undo", so-to-speak, what the user did while
maintaining legibility.
Consider if the user specified "all_enabled_vlans='net1'" and then
decided they wanted to backout of this decision. What is the proper
argument to fulfill this wish? "all_enabled_vlans='...?'
This patch changes the all_enabled_vlans argument to be "enabled_vlans",
ensures that idempotency works, and also provides for a way to "undo" a
change to the enabled VLANs by allowing the user to specify the special
case VLAN named "ALL" (all capitals).
This makes the parameter more intuitive because the users will specify
which vlans they want to make the virtual available on
* enabled_vlans="net1"
but also allows them to "undo" what they did by setting it back with
the case of all
* enabled_vlans="ALL"
We were incorrectly making VLANS always be untagged when they could
be either tagged or untagged. This change corrects the arguments to
the vlan module to allow for specifying either untagged or tagged
interfaces. The arguments are mutually exclusive
The code for traffic groups was not being tested and therefore
had errors associated with it. It is now covered in coverage tests
and bugs that were found in it have been fixed.
See this issue for details
https://github.com/F5Networks/f5-ansible/issues/28
In the six package, the map() function returns an iterator instead
of a list. This code was continuing to use the map() return value
as if it were a list and this broke the address_class facts.
This patch changes the code to use the list() method on the return
value of map().
The domains method was not defined, and therefore when specifying
a parent domain during route domain creation, the process would
fail.
Tests have been added to detect this going forward
Adds bigip_ssl_certificate module
This module is another in the ongoing "bootstrapping saga" that is
being undertaken. With this module you can manage the lifecycle of
the SSL certificates on a BIG-IP. This includes those used for
SSL offloading.
Tests for this module can be found here
https://github.com/F5Networks/f5-ansible/blob/master/roles/__bigip_ssl_certificate/tasks/main.yaml
Platforms this was tested on are
12.0.0
12.1.0
Recently, a user reported that the bigip_facts module was failing with the error
received exception: object of type 'itertools.imap' has no len()
This reported was occurring at line 1657 of the bigip_facts module
bug report is here
https://github.com/F5Networks/f5-ansible/issues/25
Upon further investigation, the map function for returning the specified
includes was returning an iterator, and calling len() on an iterator does
not work.
I believe this problem was caused by part of the Python 3.x effort insofar
as the inclusion of this line
https://github.com/ansible/ansible/blob/devel/lib/ansible/module_utils/basic.py#L143
seems to affect our usage of map(), probably for the better anyway, and we need
to change our expectations in our module's code to no longer assume a list, but
instead assume an iterator.
After trawling through the module_utils/basic code, I think a list
comprehension is more appropriate here anyway, so I'm changing it to be
that. The affected user reported it works this way, and my own testing
on 2.2.0 supports that.
This parameter can be used to open up access to (among other things)
the mgmt address of a BIG-IP. It is necessary for configuring bigips
in an HA configuration.
This module can be used to maintain the iRules for both LTM and GTM
on a BIG-IP. iRules should be supplied in their string form using
normal strings (unlikely), file lookups (likely), or template
lookups (likely).
Tests for this module can be found here
https://github.com/F5Networks/f5-ansible/blob/master/roles/__bigip_irule/tasks/main.yaml
Platforms this was tested on are
11.6.1
12.0.0
12.1.0
This module can be used to manipulate data centers in a BIG-IP.
It supports both the iControl SOAP and iControl REST APIs, but default
to the REST API. With this module, you can perform operations similar
to those available in tmsh to create data centers and set the contact,
location, and description of those data centers.
This module is most useful in the initial provisioning of a BIG-IP
This module can be used to directly manipulate the system database
variables in a BIG-IP. It supports both the iControl SOAP and iControl
REST APIs, but default to the REST API. With this module, you can
perform operations similar to those available in tmsh to set system
variables such as turning off the default setup screen.
This module is most useful in the initial provisioning of a BIG-IP
This module can be used to manage VLANs in BIG-IP on various software
versions. It is part of a bootstrapping effort underway to provide
modules necessary to bootstrap core settings in a BIG-IP.
Tests for this module can be found here
https://github.com/F5Networks/f5-ansible/blob/master/roles/__bigip_vlan/tasks/main.yaml
Platforms this was tested on are
- 11.5.4 HF1
- 11.6.0
- 12.0.0
- 12.1.0 HF1
A number of coding conventions have been adopted for new F5 modules
that are in development. To ensure common usage across the modules,
this module needed to be updated to reflect those conventions.
No functional code changes were made.
A number of coding conventions have been adopted for new F5 modules
that are in development. To ensure common usage across the modules,
this module needed to be updated to reflect those conventions.
Additionally, this patch fixes a couple bugs in the module that were
preventing it from being idempotent.
A number of coding conventions have been adopted for new F5 modules
that are in development. To ensure common usage across the modules,
this module needed to be updated to reflect those conventions.
No functional code changes were made.
A number of coding conventions have been adopted for new F5 modules
that are in development. To ensure common usage across the modules,
this module needed to be updated to reflect those conventions.
No functional code changes were made.
A number of coding conventions have been adopted for new F5 modules
that are in development. To ensure common usage across the modules,
this module needed to be updated to reflect those conventions.
No functional code changes were made.
A number of coding conventions have been adopted for new F5 modules
that are in development. To ensure common usage across the modules,
this module needed to be updated to reflect those conventions.
No functional code changes were made.
A number of coding conventions have been adopted for new F5 modules
that are in development. To ensure common usage across the modules,
this module needed to be updated to reflect those conventions.
This patch adds support for the server_port module. It
additionally updates the documentation in the module for
it.
The changes were tested in the f5-ansible repository to
ensure no breaking changes were made. This argument allows
modules to be used on BIG-IPs that are listening on
non-standard ports.
Instead of doing an unpack, deliberately specify which parameters you
want to use. This allows us to flexibly add more parameters to the
f5_argument_spec without having to rewrite all the modules that use
it.
Functionally this commit changes nothing, it just provides for a
different way of accessing the parameters to the module
As is done in other ansible modules, this adds the __main__ check
to the module so that the module code itself can be used as a library.
For instance, when testing the code.
Tim Rupp