add eol banner

(cherry picked from commit 00699735e9)

.github/ISSUE_TEMPLATE.md

@@ -13,7 +13,7 @@ Also test if the latest release, and master branch are affected too.
 <!--- Name of the module/plugin/task/feature -->
 
 ##### ANSIBLE VERSION
-<!--- Paste verbatim output from “ansible --version” between quotes below -->
+<!--- Paste verbatim output from "ansible --version" between quotes below -->
 ```
 
 ```
@@ -27,7 +27,7 @@ Mention any settings you have changed/added/removed in ansible.cfg
 ##### OS / ENVIRONMENT
 <!---
 Mention the OS you are running Ansible from, and the OS you are
-managing, or say “N/A” for anything that is not platform-specific.
+managing, or say "N/A" for anything that is not platform-specific.
 Also mention the specific version of what you are trying to control,
 e.g. if this is a network bug the version of firmware on the network device.
 -->

.github/PULL_REQUEST_TEMPLATE.md

@@ -18,7 +18,7 @@ the change does.
 <!--- Name of the module/plugin/module/task -->
 
 ##### ANSIBLE VERSION
-<!--- Paste verbatim output from “ansible --version” between quotes below -->
+<!--- Paste verbatim output from "ansible --version" between quotes below -->
 ```
 
 ```

.gitignore

@@ -35,9 +35,11 @@ docs/docsite/rst/*_module.rst
 docs/docsite/rst/modules_by_category.rst
 docs/docsite/rst/network_maintained.rst
 docs/docsite/rst/partner_maintained.rst
-docs/docsite/rst/playbook_keywords.rst
+docs/docsite/rst/playbooks_keywords.rst
 docs/docsite/rst/playbooks_directives.rst
 docs/docsite/*.html
+docs/docsite/rst/ansible.rst
+docs/docsite/rst/ansible-*.rst
 docs/docsite/_static/*.gif
 docs/docsite/_static/*.png
 docs/docsite/_static/websupport.js
@@ -62,6 +64,7 @@ results.xml
 coverage.xml
 /test/units/cover-html
 /test/integration/targets/*/backup/
+/test/cache/*
 # Development
 /test/develop
 venv

CHANGELOG.md

@@ -1,7 +1,622 @@
 Ansible Changes By Release
 ==========================
 
-## 2.4 "Dancing Days" - ACTIVE DEVELOPMENT
+<a id="2.4.7"></a>
+
+## 2.4.7 "Dancing Days" - TBD
+
+### Bugfixes
+
+* The fix for CVE-2018-10875 (https://access.redhat.com/security/cve/cve-2018-10875)
+  prints out a warning message about skipping a config file from a world
+  writable current working directory.  However, if the user explicitly
+  specifies that the config file should be used via the ANSIBLE_CONFIG
+  environment variable then Ansible would honor that but still print out the
+  warning message.  This has been fixed so that Ansible honors the user's
+  explicit wishes and does not print a warning message in that circumstance.
+
+
+<a id="2.4.6"></a>
+
+## 2.4.6 "Dancing Days" - 2018-07-05
+
+### Bugfixes
+* **Security Fix** - avoid loading host/group vars from cwd when not specifying
+  a playbook or playbook base dir (https://github.com/ansible/ansible/pull/42067)
+* **Security Fix** - avoid using ansible.cfg in a world writable dir
+  https://github.com/ansible/ansible/pull/42070
+
+
+<a id="2.4.5"></a>
+
+## 2.4.5 "Dancing Days" - 2018-06-21
+
+### Bugfixes
+
+* **Security Fix** - Some connection exceptions would cause no_log specified on
+  a task to be ignored.  If this happened, the task information, including any
+  private information could have been displayed to stdout and (if enabled, not
+  the default) logged to a log file specified in ansible.cfg''s log_path.
+  Additionally, sites which redirected stdout from ansible runs to a log file
+  may have stored that private information onto disk that way as well.
+  (https://github.com/ansible/ansible/pull/41414)
+
+* Fix win_copy to preserve the global Ansible local tmp path instead of
+  deleting it when dealing with multiple files
+  (https://github.com/ansible/ansible/pull/37964)
+* Fix Windows setup.ps1 for slow performance in large domain environments
+  (https://github.com/ansible/ansible/pull/38646)
+* Fix eos_logging idempotency issue when trying to set both logging destination & facility
+  (https://github.com/ansible/ansible/pull/40604)
+* Fix ios_logging idempotency issue when trying to set both logging destination & facility
+  (https://github.com/ansible/ansible/pull/41076)
+
+
+
+<a id="2.4.4"></a>
+
+## 2.4.4 "Dancing Days" - 2018-04-04
+
+### Bugfixes
+* Fix python 3 dictionary runtime error in ios_confg and eos_config
+  (https://github.com/ansible/ansible/issues/36717)
+* Fix `win_script` to work with large arguments and removed uneeded function
+  that produces errors and was not needed
+  (https://github.com/ansible/ansible/pull/33855)
+* Fix timeout when using piped ssh transfer with become
+  https://github.com/ansible/ansible/issues/34523
+* Fix win_scheduled_task docs to correctly reflect what is required and when
+  (https://github.com/ansible/ansible/issues/35072)
+* Updated copy test to create recursive symlink during the test and not have it
+  located in the git repo
+  (https://github.com/ansible/ansible/pull/35073)
+* Fix Digital Ocean tags data type due to backend API changes no longer
+  acceping integers
+  (https://github.com/ansible/ansible/pull/33486)
+* Fix for nxos_vxlan_vtep_vni issues: https://github.com/ansible/ansible/pull/34946
+* Fixes for nxos_bgp: https://github.com/ansible/ansible/pull/34590
+* Enable nxapi nxos_banner test: https://github.com/ansible/ansible/pull/35033
+* fix vxlan idempotent issue in nxos_vxlan_vtep: https://github.com/ansible/ansible/pull/34750
+* Fix win_dns_client to allow setting dynamic IP from static IP
+  (https://github.com/ansible/ansible/pull/35149)
+* Fix azure_rm_subnet absent idempotency issues
+  (https://github.com/ansible/ansible/pull/35037)
+* Fix azure_rm_virtualmachine creating VM with vnet in another resource group
+  (https://github.com/ansible/ansible/pull/35038)
+* Fix nxos terminal plugin regex to support certain commands
+  (https://github.com/ansible/ansible/pull/35186)
+* Fix network os_config modules backward diff
+  (https://github.com/ansible/ansible/pull/35332)
+* Fix nxos_snmp_user removing encryption from user on subsequent runs of the task
+  (https://github.com/ansible/ansible/pull/35433)
+* Fix traceback in winrm module when the ipaddress module is not installed
+  https://github.com/ansible/ansible/pull/35723/files
+* Fix bug in `lineinfile` where the line would not be inserted when using `insertbefore` or `insertafter` if the pattern occured anywhere in the file. (https://github.com/ansible/ansible/issues/28721)
+* Fix connection local getting overridden by network_cli for transport nxapi,eapi for platform agnostic modules
+  (https://github.com/ansible/ansible/pull/35590)
+* Include dest i nthe results from file copy:
+  https://github.com/ansible/ansible/pull/35702/
+* Fix eos_config second-level indent idempotece
+  https://github.com/ansible/ansible/pull/35588
+* Fix the removed_in_version to 2.6 ios_config force option
+  https://github.com/ansible/ansible/pull/35853
+* Fix memory ballooning caused as a result of task caching changes
+  https://github.com/ansible/ansible/pull/35921
+* Fix nxos_igmp_interface for diff nxos versions
+  (https://github.com/ansible/ansible/pull/35959)
+* Fix recursion error with many flat includes
+  (https://github.com/ansible/ansible/pull/36075)
+* Fix win_uri to work with `creates` and `removed` option
+  (https://github.com/ansible/ansible/pull/36016)
+* Fix the oom_killer parameter to docker_container not being honored
+  https://github.com/ansible/ansible/pull/34130
+* Fix docker_service so a build is not triggered every time
+  https://github.com/ansible/ansible/issues/36145
+* Be more tolerant about spaces when gathering virtual facts (https://github.com/ansible/ansible/pull/36042)
+* validate add_host name parameter (https://github.com/ansible/ansible/pull/36055)
+* spelling fixes (https://github.com/ansible/ansible/pull/36007)
+* avoid needles vault prompt on ansible-console (https://github.com/ansible/ansible/pull/36244)
+* fix callback function signatures (https://github.com/ansible/ansible/pull/35664)
+* Clarify error message from convert_bool()
+  https://github.com/ansible/ansible/pull/36041
+* Fix EC2 C5 instance_type fact to be kvm:
+  https://github.com/ansible/ansible/pull/35063
+* Fix templating of loop_control properties:
+  https://github.com/ansible/ansible/pull/36124
+* Fix dependency in the deb package on Ubuntu-12.04:
+  https://github.com/ansible/ansible/pull/36407
+* Fix WinRM Python 3 encoding when getting Kerberos ticket
+  (https://github.com/ansible/ansible/issues/36255)
+* Always show custom prompt in pause module
+  (https://github.com/ansible/ansible/issues/36057)
+* Improve performance and recursion depth in include_role
+  (https://github.com/ansible/ansible/pull/36470)
+* Fix using ansible_*_interpreter on Python3 with non-new-style modules
+  (old-style ansible python modules, modules written in another language, etc)
+  https://github.com/ansible/ansible/pull/36541
+* Fix vyos_config IndexError in sanitize_config
+  (https://github.com/ansible/ansible/issues/36351)
+* Fix vyos_l3_interface multiple address assignment to interfaces
+  (https://github.com/ansible/ansible/pull/36721)
+* Protect from inventory plugins using verify incorrectly
+  https://github.com/ansible/ansible/pull/36591
+* loop control templating
+  https://github.com/ansible/ansible/pull/36124
+* fix debug output
+  https://github.com/ansible/ansible/pull/36307
+* Fix credentials for Ansible Tower modules to work with v1 and v2 of the API
+  (https://github.com/ansible/ansible/pull/36587)
+  (https://github.com/ansible/ansible/pull/36662)
+* Python3 fixes:
+  * Fix for the znode zookeeper module: https://github.com/ansible/ansible/pull/36999
+  * Fix for the maven_artifact module: https://github.com/ansible/ansible/pull/37035
+* Add changes to get docker_container, docker_common, and docker_network
+  working with Docker SDK 3.x: https://github.com/ansible/ansible/pull/36973
+* Ensure we install ansible-config and ansible-inventory with `pip install -e`
+  (https://github.com/ansible/ansible/pull/37151)
+* Fix for unarchive when users use the --strip-components extra_opt to tar
+  causing ansible to set permissions on the wrong directory.
+  https://github.com/ansible/ansible/pull/37048
+* Fix powershell plugin to handle special chars in environment keys as well as
+  int and bool values
+  (https://github.com/ansible/ansible/pull/37215)
+* Fix error messages to not be inappropriately templated:
+  https://github.com/ansible/ansible/pull/37329
+* Fix Python 3 error in the openssl_certificate module:
+  https://github.com/ansible/ansible/pull/35143
+* Fix traceback when creating or stopping ovirt vms
+  (https://github.com/ansible/ansible/pull/37249)
+* Connection error messages may contain characters that jinja2 would
+  interpret as a template.  Wrap the error string so this doesn't happen
+  (https://github.com/ansible/ansible/pull/37329)
+* Fix python3 compatibility bug in wait_for_connection
+  (https://github.com/ansible/ansible/pull/37646)
+* Fix output of the interfaces_file module:
+  https://github.com/ansible/ansible/pull/37818/files
+* Fix haproxy traceback on Python 3 https://github.com/ansible/ansible/pull/35176
+* Fix the csvfile lookup plugin for python3 tracebacks: https://github.com/ansible/ansible/pull/37665
+* Fix ec2 user_data parameter to properly convert to base64 on python3 (https://github.com/ansible/ansible/pull/37628)
+* ansible-pull - fixed a bug checking for changes when we've pulled from the
+  git repository on python3 https://github.com/ansible/ansible/issues/36962
+* Fix digital_ocean module unique_name parameter for a python3 bug:
+  https://github.com/ansible/ansible/issues/37114
+* Fix a Python3 bug in the vagrant dynamic inventory script: https://github.com/ansible/ansible/pull/37631
+* Fix python3 bug in the jira module: https://github.com/ansible/ansible/pull/33862
+* Fix consul module's state=absent: https://github.com/ansible/ansible/issues/34628
+* fix required args for nxos_snapshot: https://github.com/ansible/ansible/pull/37232
+* Properly check that nxos_snapshot parameters that are required in certain circumstances are present:
+  https://github.com/ansible/ansible/pull/37232
+* Fix error messages to not be inappropriately templated:
+  https://github.com/ansible/ansible/pull/37329
+* Fix Python 3 error in the openssl_certificate module:
+  https://github.com/ansible/ansible/pull/35143
+* Fix nxos enable mode
+  https://github.com/ansible/ansible/pull/39898
+
+
+<a id="2.4.3"></a>
+
+## 2.4.3 "Dancing Days" - 2018-01-31
+
+### Bugfixes
+* Fix `pamd` rule args regexp to match file paths (https://github.com/ansible/ansible/pull/33432)
+* Check if SELinux policy exists before setting (https://github.com/ansible/ansible/pull/31834)
+* Set locale to `C` in `letsencrypt` module to fix date parsing errors (https://github.com/ansible/ansible/pull/31339)
+* Fix include in loop when stategy=free
+  (https://github.com/ansible/ansible/pull/33094)
+* Fix save parameter in asa_config (https://github.com/ansible/ansible/pull/32761)
+* Fix --vault-id support in ansible-pull (https://github.com/ansible/ansible/pull/33629)
+* In nxos_interface_ospf, fail nicely if loopback is used with passive_interface:
+  (https://github.com/ansible/ansible/pull/33252)
+* Fix quote filter when given an integer to quote (https://github.com/ansible/ansible/issues/33272)
+* nxos_vrf_interface fix when validating the interface (https://github.com/ansible/ansible/issues/33227)
+* Fix for win_copy when sourcing files from an SMBv1 share
+  (https://github.com/ansible/ansible/pull/33576)
+* correctly report callback plugin file
+* restrict revaulting to vault cli
+  https://github.com/ansible/ansible/pull/33656
+* Fix python3 tracebacks in letsencrypt module (https://github.com/ansible/ansible/pull/32734)
+* Fix ansible_*_interpreter variables to be templated prior to being used:
+  https://github.com/ansible/ansible/pull/33698
+* Fix setting of environment in a task that uses a loop:
+  https://github.com/ansible/ansible/issues/32685
+* Fix fetch on Windows failing to fetch files or particular block size
+  (https://github.com/ansible/ansible/pull/33697)
+* preserve certain fields during no log. https://github.com/ansible/ansible/pull/33637
+* fix issue with order of declaration of sections in ini inventory https://github.com/ansible/ansible/pull/33781
+* Fix win_iis_webapppool to correctly stop a apppool
+  (https://github.com/ansible/ansible/pull/33777)
+* Fix CloudEngine host failed (https://github.com/ansible/ansible/pull/27876)
+* Fix ios_config save issue (https://github.com/ansible/ansible/pull/33791)
+* Handle vault filenames with nonascii chars when displaying messages (https://github.com/ansible/ansible/pull/33926)
+* Fix win_iis_webapppool to not return passwords
+  (https://github.com/ansible/ansible/pull/33931)
+* Fix extended file attributes detection and changing:
+  (https://github.com/ansible/ansible/pull/18731)
+* correctly ensure 'ungrouped' membership rules (https://github.com/ansible/ansible/pull/33878)
+* made warnings less noisy when empty/no inventory is supplied (https://github.com/ansible/ansible/pull/32806)
+* Fixes a failure which prevents to create servers in module cloudscale_server
+* Fix win_firewall_rule "Specified cast is invalid" error when modifying a rule with all of Domain/Public/Private profiles set (https://github.com/ansible/ansible/pull/34383)
+* Fix case for multilib when installing from a file in the yum module
+  (https://github.com/ansible/ansible/pull/32236)
+* Fix WinRM parsing/escaping of IPv6 addresses (https://github.com/ansible/ansible/pull/34072)
+* Fix win_package to detect MSI regardless of the extension case
+  (https://github.com/ansible/ansible/issues/34465)
+* Updated win_mapped_drive docs to clarify what it is used for
+  (https://github.com/ansible/ansible/pull/34478)
+* Fix file related modules run in check_mode when the file being operated on does not exist
+  (https://github.com/ansible/ansible/pull/33967)
+* Make eos_vlan idempotent
+  (https://github.com/ansible/ansible/pull/34443)
+* Fix win_iis_website to properly check attributes before setting
+  (https://github.com/ansible/ansible/pull/34501)
+* Fixed the removal date for ios_config save and force parameters
+  (https://github.com/ansible/ansible/pull/33885)
+* cloudstack: fix timeout from ini config file being ignored
+  https://github.com/ansible/ansible/pull/34854
+* fixes memory usage issues with many blocks/includes
+  https://github.com/ansible/ansible/issues/31673
+  https://github.com/ansible/ansible/pull/34461
+* Fixes maximum recursion depth exceeded with include_role
+  https://github.com/ansible/ansible/issues/23609
+* Fix to win_dns_client module to take ordering of DNS servers to resolve into account:
+  https://github.com/ansible/ansible/pull/34656
+* Fix for the nxos_banner module where some nxos images nest the output inside of an additional dict:
+  https://github.com/ansible/ansible/pull/34695
+* Fix failure message "got multiple values for keyword argument id" in the
+  azure_rm_securitygroup module (caused by changes to the azure python API):
+  https://github.com/ansible/ansible/pull/34810
+* Bump Azure storage client minimum to 1.5.0 to fix deserialization issues. This will break Azure Stack
+  until it receives storage API version 2017-10-01 or changes are made to support multiple versions.
+  (https://github.com/ansible/ansible/pull/34442)
+* Flush stdin when passing the become password.  Fixes some cases of timeout on
+  Python 3 with the ssh connection plugin: https://github.com/ansible/ansible/pull/35049
+
+
+<a id="2.4.2"></a>
+
+## 2.4.2 "Dancing Days" - 2017-11-29
+
+### Bugfixes
+
+* Fix formatting typo in panos_security_rule.py docs. (https://github.com/ansible/ansible/commit/c0fc797a06451d2fe1ac4fc077fc64f3a1666447)
+* Fix rpm spec file to build on RHEL6 without EPEL packages (https://github.com/ansible/ansible/pull/31653)
+* Keep hosts in play vars if inside of a rescue task (https://github.com/ansible/ansible/pull/31710)
+* Fix wait_for module to treat broken connections as unready so that the connection continues to be retried:
+  https://github.com/ansible/ansible/pull/28839
+* Python3 fixes:
+  * windows_azure, clc_firewall_policy, and ce_template modules fixed for
+    imports of urllib which changed between Python2 and Python3 lookup plugin
+    for consul_kv.py fixed for imports of urllib
+    (https://github.com/ansible/ansible/issues/31240)
+  * Make internal hashing of hostvars use bytes on both python2 and python3
+    (https://github.com/ansible/ansible/pull/31788)
+* Fix logging inside of KubernetesAnsibleModule() to not use
+  self.helper.logging.  the Ansible builtin log() method will strip out
+  parameters marked no_log and will not log if no_log was set in the playbook.
+  self.helper.log() circumvents that (https://github.com/ansible/ansible/pull/31789)
+* Correct task results display so that it more closely matches what was present
+  in 2.3.x and previous.
+* Warn when a group has a bad key (Should be one of vars, children, or hosts)
+  https://github.com/ansible/ansible/pull/31495
+* Use controller configured ansible_shell_executable to run commands in the module
+  (https://github.com/ansible/ansible/pull/31361)
+* Add documentation about writing unittests for Ansible
+* Fix bugs in get_url/uri's SNI and TLS version handling when used on systems
+  that have Python-2.7.9+ and urllib3 installed.
+* Have ansible-pull process inventory in its own way.  Fixes issues with
+  ansible-pull not using the correct inventory,  especially for localhost
+  (https://github.com/ansible/ansible/pull/32135)
+* Fix for implicit localhost receiving too many variables from the all group
+  (https://github.com/ansible/ansible/pull/31959)
+* Fix the service module to correctly detect which type of init system is
+  present on the host. (https://github.com/ansible/ansible/pull/32086)
+* Fix inventory patterns to convert to strings before processing:
+  (https://github.com/ansible/ansible/issues/31978)
+* Fix traceback in firewalld module instead of a nice error message:
+  (https://github.com/ansible/ansible/pull/31949)
+* Fix for entering privileged mode using eos network modules:
+  (https://github.com/ansible/ansible/issues/30802)
+* Validate that the destination for ansible-pull is a valid.directory:
+  (https://github.com/ansible/ansible/pull/31499)
+* Document how to preserve strings of digits as strings in the ini inventory:
+  (https://github.com/ansible/ansible/pull/32047)
+* Make sure we return ansible_distribution_major_version to macOS:
+  (https://github.com/ansible/ansible/pull/31708)
+* Fix to ansible-doc -l to list custom inventory plugins:
+  (https://github.com/ansible/ansible/pull/31996)
+* Fix win_chocolatey to respect case sensitivity in URLs:
+  (https://github.com/ansible/ansible/pull/31983)
+* Fix config_format json in the junos_facts module:
+  (https://github.com/ansible/ansible/pull/31818)
+* Allow the apt module's autoremove parameter to take effect in upgrades:
+  (https://github.com/ansible/ansible/pull/30747)
+* When creating a new use via eos_user, create the user before setting the
+  user's privilege level: (https://github.com/ansible/ansible/pull/32162)
+* Fixes nxos_portchannel idempotence failure on N1 images:
+  (https://github.com/ansible/ansible/pull/31057)
+* Remove provider from prepare_ios_tests integration test:
+  (https://github.com/ansible/ansible/pull/31038)
+* Fix nxos_acl change ports to non well known ports and drop time_range for N1:
+  (https://github.com/ansible/ansible/pull/31261)
+* Fix nxos_banner removal idempotence issue in N1 images:
+  (https://github.com/ansible/ansible/pull/31259)
+* Return error message back to the module
+  (https://github.com/ansible/ansible/pull/31035)
+* Fix nxos_igmp_snooping idempotence:
+  (https://github.com/ansible/ansible/pull/31688)
+* NXOS integration test nxos_file_copy, nxos_igmp, nxos_igmp_interface
+  nxos_igmp_snooping, nxos_ntp_auth, nxos_ntp_options:
+  (https://github.com/ansible/ansible/pull/29030)
+* Fix elb_target_group module traceback when ports were specified inside of the targets parameter:
+  (https://github.com/ansible/ansible/pull/32202)
+* Fix creation of empty virtual directories in aws_s3 module:
+  (https://github.com/ansible/ansible/pull/32169)
+* Enable echo for `pause` module: (https://github.com/ansible/ansible/issues/14160)
+* Fix for `hashi_vault` lookup to return all keys at a given path when no key is specified (https://github.com/ansible/ansible/pull/32182)
+* Fix for `win_package` to allow TLS 1.1 and 1.2 on web requests:
+  (https://github.com/ansible/ansible/pull/32184)
+* Remove provider from ios integration test:
+  (https://github.com/ansible/ansible/pull/31037)
+* Fix eos_user tests
+  (https://github.com/ansible/ansible/pull/32261)
+* Fix ansible-galaxy --force with installed roles:
+  (https://github.com/ansible/ansible/pull/32282)
+* ios_interface testfix:
+  (https://github.com/ansible/ansible/pull/32335)
+* Fix ios integration tests:
+  (https://github.com/ansible/ansible/pull/32342)
+* Ensure there is always a basdir so we always pickup group/host_vars
+  https://github.com/ansible/ansible/pull/32269
+* Fix vars placement in ansible-inventory
+  https://github.com/ansible/ansible/pull/32276
+* Correct options for luseradd in user module
+  https://github.com/ansible/ansible/pull/32262
+* Clarified package docs on 'latest' state
+  https://github.com/ansible/ansible/pull/32397
+* Fix issue with user module when local is true
+  (https://github.com/ansible/ansible/pull/32262 and https://github.com/ansible/ansible/pull/32411)
+* Fix for max_fail_percentage being inaccurate:
+  (https://github.com/ansible/ansible/issues/32255)
+* Fix check mode when deleting ACS instance in azure_rm_acs module:
+  (https://github.com/ansible/ansible/pull/32063)
+* Fix ios_logging smaller issues and make default size for buffered work:
+  (https://github.com/ansible/ansible/pull/32321)
+* Fix ios_logging module issue where facility is being deleted along with host:
+  (https://github.com/ansible/ansible/pull/32234)
+* Fix wrong prompt issue for network modules (https://github.com/ansible/ansible/pull/32426)
+* Fix eos_eapi to enable non-default vrfs if the default vrf is already configured (https://github.com/ansible/ansible/pull/32112)
+* Fix network parse_cli filter in case of single match is not caught when using start_block and end_block
+  (https://github.com/ansible/ansible/pull/31092)
+* Fix win_find failing on files it can't access, change behaviour to be more
+  like the find module (https://github.com/ansible/ansible/issues/31898)
+* Amended tracking of 'changed'
+  https://github.com/ansible/ansible/pull/31812
+* Fix label assignment in ovirt_host_networks
+  (https://github.com/ansible/ansible/pull/31973)
+* Fix fencing and kuma usage in ovirt_cluster module
+  (https://github.com/ansible/ansible/pull/32190)
+* Fix failure during upgrade due to NON_RESPONSIVE state for ovirt_hosts module
+  (https://github.com/ansible/ansible/pull/32192)
+* ini inventory format now correclty handles group creation w/o need for specific orders
+  https://github.com/ansible/ansible/pull/32471
+* Fix for quoted paths in win_service
+  (https://github.com/ansible/ansible/issues/32368)
+* Fix tracebacks for non-ascii paths when parsing inventory
+  (https://github.com/ansible/ansible/pull/32511)
+* Fix git archive when update is set to no
+  (https://github.com/ansible/ansible/pull/31829)
+* Fix locale when screen scraping in the yum module
+  (https://github.com/ansible/ansible/pull/32203)
+* Fix for validating proxy results on Python3 for modules making http requests:
+  (https://github.com/ansible/ansible/pull/32596)
+* Fix unreferenced variable in SNS topic module
+  (https://github.com/ansible/ansible/pull/29117)
+* Handle ignore_errors in loops
+  (https://github.com/ansible/ansible/pull/32546)
+* Fix running with closed stdin on python 3
+  (https://github.com/ansible/ansible/pull/31695)
+* Fix undefined variable in script inventory plugin
+  (https://github.com/ansible/ansible/pull/31381)
+* Fix win_copy on Python 2.x to support files greater than 4GB
+  (https://github.com/ansible/ansible/pull/32682)
+* Add extra error handling for wmare connect to correctly detect scenarios where
+  username does not have the required logon permissions
+  (https://github.com/ansible/ansible/pull/32613)
+* Fix ios_config file prompt issue while using save_when
+  (https://github.com/ansible/ansible/pull/32744)
+* Prevent host_group_vars plugin load errors when using 'path as inventory hostname'
+  https://github.com/ansible/ansible/issues/32764
+* Better errors when loading malformed vault envelopes
+  (https://github.com/ansible/ansible/issues/28038)
+* nxos_interface error handling
+  (https://github.com/ansible/ansible/pull/32846)
+* Fix snmp bugs on Nexus 3500 platform
+  (https://github.com/ansible/ansible/pull/32773)
+* nxos_config and nxos_facts - fixes for N35 platform
+  (https://github.com/ansible/ansible/pull/32762)
+* fix dci failure nxos
+  (https://github.com/ansible/ansible/pull/32877)
+* Do not execute `script` tasks is check mode (https://github.com/ansible/ansible/issues/30676)
+* Keep newlines when reading LXC container config file (https://github.com/ansible/ansible/pull/32219)
+* Fix a traceback in os_floating_ip when required instance is already present in the cloud:
+  https://github.com/ansible/ansible/pull/32887
+* Fix for modifying existing application load balancers using certificates (https://github.com/ansible/ansible/pull/28217)
+* Fix --ask-vault-pass with no tty and password from stdin
+  (https://github.com/ansible/ansible/issues/30993)
+* Fix for IIS windows modules to use hashtables instead of PSCustomObject
+  (https://github.com/ansible/ansible/pull/32710)
+* Fix nxos_snmp_host bug
+  (https://github.com/ansible/ansible/pull/32916)
+* Make IOS devices consistent ios_logging
+  (https://github.com/ansible/ansible/pull/33100)
+* restore error on orphan group:vars delcaration for ini inventories
+  https://github.com/ansible/ansible/pull/32866
+* restore host/group_vars merge order
+  https://github.com/ansible/ansible/pull/32963
+* use correct loop var when delegating
+  https://github.com/ansible/ansible/pull/32986
+* Handle sets and datetime objects in inventory sources fixing tracebacks
+  https://github.com/ansible/ansible/pull/32990
+* Fix for breaking change to Azure Python SDK DNS RecordSet constructor in azure-mgmt-dns==1.2.0
+  https://github.com/ansible/ansible/pull/33165
+* Fix for breaking change to Azure Python SDK that prevented some members from being returned in facts modules
+  https://github.com/ansible/ansible/pull/33169
+* restored glob/regex host pattern matching to traverse groups and hosts and not return after first found
+  https://github.com/ansible/ansible/pull/33158
+* change nxos_interface module to use "show interface" to support more platforms
+  https://github.com/ansible/ansible/pull/33037
+
+
+<a id="2.4.1"></a>
+
+## 2.4.1 "Dancing Days" - 2017-10-25
+
+### Bugfixes
+
+* Security fix for CVE-2017-7550 the jenkins_plugin module was logging the jenkins
+  server password if the url_password was passed via the params field:
+  https://github.com/ansible/ansible/pull/30875
+* Update openssl\* module documentation to show openssl-0.16 is the minimum version
+* Fix openssl_certificate's csr handling
+* Python-3 fixes
+  * Fix openssl_certificate parameter assertion on Python3
+  * Fix for python3 and nonascii strings in inventory plugins (https://github.com/ansible/ansible/pull/30666)
+  * Fix missing urllib in iam_policy
+  * Fix crypttab module for bytes<=>text string mismatch ( https://github.com/ansible/ansible/pull/30457 )
+  * Fix lxc_container module combining bytes with text ( https://github.com/ansible/ansible/pull/30572 )
+  * Fix map doesn't return a list on python3 in ec2_snapshot_facts module (https://github.com/ansible/ansible/pull/30606)
+  * Fix uri (and other url retrieving) modules when used with a proxy. (https://github.com/ansible/ansible/issues/31109)
+  * Fix azure_rm dynamic inventory script ConfigParser usage.
+* Fix for win_file to respect check mode when deleting directories
+* Fix for Ansible.ModuleUtils.Legacy.psm1 to return list params correctly
+* Fix for a proper logout in the module ovirt_vms
+* Fixed docs for 'password' lookup
+* Corrected and added missing feature and porting docs for 2.4
+* Fix for Ansible.ModuleUtils.CamelConversion to handle empty lists and lists with one entry
+* Fix nxos terminal regex to parse username correctly.
+* Fix colors for selective callback
+* Fix for 'New password' prompt on 'ansible-vault edit' (https://github.com/ansible/ansible/issues/30491)
+* Fix for 'ansible-vault encrypt' with vault_password_file in config and --ask-vault-pass cli (https://github.com/ansible/ansible/pull/30514#pullrequestreview-63395903)
+* updated porting guide with notes for callbacks and config
+* Added backwards compatiblity shim for callbacks that do not inherit from CallbackBase
+* Corrected issue with configuration and multiple ini entries being overwriten even when not set.
+* backported fix for doc generation (plugin_formatter)
+* Fix ec2_lc module for an unknown parameter name (https://github.com/ansible/ansible/pull/30573)
+* Change configuration of defaults to use standard jinja2 instead of custom
+  eval() for using variables in the default field of config (https://github.com/ansible/ansible/pull/30650)
+* added missing entry in chlog deprecation
+* Fixed precedence and values for become flags and executable settings
+* Fix for win_domain_membership to throw more helpful error messages and check/fix when calling WMI function after changing workgroup
+* Fix for win_power_plan to compare the OS version's correctly and work on Windows 10/Server 2016
+* Fix module doc for typo in telnet command option
+* Fix OpenBSD pkg_mgr fact (https://github.com/ansible/ansible/issues/30623)
+* Fix encoding error when there are nonascii values in the path to the ssh binary
+* removed YAML inventory group name validation, broke existing setups and should be global in any case, and configurable
+* performance improvment for inventory, had slown down considerably from 2.3
+* Fix cpu facts on sparc64 (https://github.com/ansible/ansible/pull/30261)
+* Fix ansible_distribution fact for Arch linux (https://github.com/ansible/ansible/issues/30600)
+* remove print statements from play_context/become
+* Fix vault errors after 'ansible-vault edit' (https://github.com/ansible/ansible/issues/30575)
+* updated api doc example to match api changes
+* corrected issues with slack callback plugin
+* it is import_playbook .. not import_plays .. docs now reflect this
+* fixed typo and missed include/import conversion in import_tasks docs
+* updated porting docs with note about inventory_dir
+* removed extension requirement for yaml inventory plugin to restore previous behaviour
+* fixed ansible-pull to now correctly deal with inventory
+* corrected dig lookup docs
+* fix type handling for sensu_silence so the module works
+* added fix for win_iis_webapppool to correctly handle array elements
+* Fix bugs caused by lack of collector ordering like service_mgr being incorrect (https://github.com/ansible/ansible/issues/30753)
+* Fix os_image when the id parameter is not set in the task. ( https://github.com/ansible/ansible/pull/29147 )
+* Fix for the winrm connection to use proper task vars
+* removed typo from dig lookup docs
+* Updated win_chocolatey example to be clearer around what should be used with become
+* Fix for copy module when permissions are changed but the file contents are not ( https://github.com/ansible/ansible/issues/30556 )
+* corrected YAML_FILENAME_EXTENSIONS ini setter as key/section were swapped
+* Better error message when a yaml inventory is invalid
+* avoid include_Xs conflating vars with options
+* Fix aws_s3 module handling `encrypt` option (https://github.com/ansible/ansible/pull/31203)
+* Fix for win_msg to document and show error when message is greater than 255 characters
+* Fix for win_dotnet_ngen to work after recent regression
+* fixed backwards compat method for config
+* removed docs for prematurely added ssh specific pipelining settings
+* fixed redis cache typo
+* Fix AttributeError during inventory group deserialization (https://github.com/ansible/ansible/issues/30903)
+* Fix 'ansible-vault encrypt --output=-' (https://github.com/ansible/ansible/issues/30550)
+* restore pre 2.4 pipeline configuration options (env and ini)
+* Fix win_copy regression: handling of vault-encrypted source files (https://github.com/ansible/ansible/pull/31084)
+* Updated return values for win_reg_stat to correctly show what is being returned (https://github.com/ansible/ansible/pull/31252)
+* reduced normal error redundancy and verbosity, display on increased and when needed
+* Give an informative error instead of a traceback if include_vars dir is file instead of directory (https://github.com/ansible/ansible/pull/31157)
+* Fix monit module's version check for color support (https://github.com/ansible/ansible/pull/31212)
+* Make `elasticsearch_plugin` module work with both 2.x and 5.x (https://github.com/ansible/ansible/issues/21989)
+* Fix for become on Windows to handle ignored errors (https://github.com/ansible/ansible/issues/30468)
+* Fix removal of newlines when writing SELinux config (https://github.com/ansible/ansible/issues/30618)
+* clarified extension requirement for constructed inv plugin
+* really turn off inventory caching, toggle will be added in 2.5
+* for inventory sources, dont follow symlinks to calculate base directory, used for group/host_vars
+* Port the uptime.py example script to the new inventory API.
+* inventory_file variable again returns full path, not just basename
+* added info about cwd group/host vars to porting guide
+* Fix name parsing out of envra in the yum module
+* give user friendly error on badly formatted yaml inventory source
+* Fix any_errors_fatal setting in playbooks.
+* Fix setting of ssh-extra-args from the cli (https://github.com/ansible/ansible/pull/31326)
+* Change SELinux fact behavior to always return a dictionary. (https://github.com/ansible/ansible/issues/18692)
+* Revert a fix for using non /bin/sh shells for modules' running commands as
+  this was causing output from commands to change, thus breaking playbooks.
+  See the original bug for details and links to the eventual fix:
+  https://github.com/ansible/ansible/issues/24169
+* Do not log data field in `docker_secrets` module (https://github.com/ansible/ansible/pull/31366)
+* Fix rpm_key taking the wrong 8 chars from the keyid (https://github.com/ansible/ansible/pull/31045)
+* chown errors now more informative
+* Fix for win_copy to copy a source file that has invalid windows characters in the filename, the dest still must be have valid windows characters (https://github.com/ansible/ansible/issues/31336#issuecomment-334649927)
+* Fix systemd module to not run daemon-reload in check mode.
+* fixed some parsing and selection issues with inventory manager, fixed minor bugs in yaml and constructed plugins
+* Fix the ping module documentation to reference win_ping instead of itself: https://github.com/ansible/ansible/pull/31444
+* Fix for ec2_win_password to allow blank key_passphrase again (https://github.com/ansible/ansible/pull/28791)
+* added toggle for vars_plugin behaviour to execute relative to playbook, set default to revert to previous way.
+* Fix for win_copy to not remove destination file on change when in check mode (https://github.com/ansible/ansible/pull/31469)
+* Fix include_role usage of role_name (https://github.com/ansible/ansible/pull/31463)
+* Fix service and package forcing a second run of the setup module to function (https://github.com/ansible/ansible/issues/31485)
+* Better error message when attempting to use include or import with /usr/bin/ansible (https://github.com/ansible/ansible/pull/31492/)
+* Fix `sysctl` module to remove etries when `state=absent` (https://github.com/ansible/ansible/issues/29920)
+* Fix for ec2_group to avoid trying to iterate over None (https://github.com/ansible/ansible/pull/31531)
+* Fix for ec2_group for a possible KeyError bug (https://github.com/ansible/ansible/pull/31540)
+* Fix for the rpm_key module when importing the first gpg key on a system (https://github.com/ansible/ansible/pull/31514)
+* Fix for aws_s3 metadata to use the correct parameters when uploading a file (https://github.com/ansible/ansible/issues/31232)
+* Fix for the yum module when installing from file/url crashes (https://github.com/ansible/ansible/pull/31529)
+* Improved error messaging for Windows become/runas when username is bogus (https://github.com/ansible/ansible/pull/31551)
+* Fix rollback feature in junos_config to now allow configuration rollback on device (https://github.com/ansible/ansible/pull/31424)
+* Remove command executed log from ansible-connection (https://github.com/ansible/ansible/pull/31581)
+* Fix relative paths to be relative to config file when there is no playbook available (https://github.com/ansible/ansible/issues/31533)
+* Fix Inventory plugins to use the configured inventory plugin path (https://github.com/ansible/ansible/issues/31605)
+* Fix include task to be dynamic (https://github.com/ansible/ansible/issues/31593)
+* A couple fixes to the test process to account for new testing resources in
+  our ci system and an upstream cryptography update that didn't work with
+  pip-8.x
+* Document backup_path in a few dellos modules and vyos_config (https://github.com/ansible/ansible/issues/31844)
+* Fix for vmware_vm_facts with dangling inaccessible VM which don't have MAC addresses (https://github.com/ansible/ansible/pull/31629)
+* Fix for win_regedit sending extra data that could confuse ansible's result parsing (https://github.com/ansible/ansible/pull/31813)
+* Fix git module to correctly cleanup temporary dirs (https://github.com/ansible/ansible/pull/31541)
+* Fix for modules which use atomic_move() to rename files raising an exception
+  if a file could not be opened.  Fix will return a nice error message instead:
+  https://github.com/ansible/ansible/issues/31786
+* Fix ansible-doc and ansible-console module-path option (https://github.com/ansible/ansible/pull/31744)
+* Fix for hostname module on RHEL 7.5 (https://github.com/ansible/ansible/issues/31811)
+* Fix provider password leak in logs for asa modules (https://github.com/ansible/ansible/issues/32343)
+* Fix tagging for dynamodb_table if region is not explicitly passed to the module (https://github.com/ansible/ansible/pull/32557)
+* Fix Python 3 decode error in `cloudflare_dns` (https://github.com/ansible/ansible/pull/32065)
+
+### Known Bugs
+* Implicit localhost is getting ansible_connection from all:vars instead of
+  from the implicit localhost definition (https://github.com/ansible/ansible/issues/31420)
+
+<a id="2.4"></a>
+
+## 2.4 "Dancing Days" - 2017-09-19
 
 ### Major Changes
 
@@ -9,8 +624,6 @@ Ansible Changes By Release
 * New import/include keywords to replace the old bare `include` directives. The use of `static: {yes|no}` on such includes is now deprecated.
     - Using `import_*` (`import_playbook`, `import_tasks`, `import_role`) directives are static.
     - Using `include_*` (`include_tasks`, `include_role`) directives are dynamic.
-* Added fact namespacing, from now on facts will be available under `ansible_facts` namespace (i.e. `ansible_facts.ansible_os_distribution`).
-  They will continue to be added into the main namespace directly, but now a configuration toggle to disable this, currently off by default, in the future it will be on by default.
   This is done to avoid collisions and possible security issues as facts come from the remote targets and they might be compromised.
 * New `order` play level keyword that allows the user to change the order in which Ansible processes hosts when dispatching tasks.
 * Users can now set group merge priority for groups of the same depth (parent child relationship), using the new `ansible_group_priority` variable, when values are the same or don't exist it will fallback to the previous sorting by name'.
@@ -22,19 +635,21 @@ Ansible Changes By Release
   - New inventory plugins for creating inventory
   - Old inventory formats are still supported via plugins
   - Inline host_list is also an inventory plugin, an example alternative `advanced_host_list` is also provided (it supports ranges)
-  - New configuration option to list enabled plugins and precedence order: `whitelist_inventory` in ansible.cfg
+  - New configuration option to list enabled plugins and precedence order `[inventory]enable_plugins` in ansible.cfg
   - vars_plugins have been reworked, they are now run from Vars manager and API has changed (need docs)
   - Loading group_vars/host_vars is now a vars plugin and can be overridden
   - It is now possible to specify mulitple inventory sources in the command line (-i /etc/hosts1 -i /opt/hosts2)
   - Inventory plugins can use the cache plugin (i.e. virtualbox) and is affected by `meta: refresh_inventory`
   - Group variable precedence is now configurable via new 'precedence' option in ansible.cfg (needs docs)
   - Improved warnings and error messages across the board
-* Configuration has been changed from a hardcoded into the constants module to dynamically loaded from yaml definitions
+* Configuration has been changed from a hardcoded listing in the constants module to dynamically loaded from yaml definitions
   - Also added an ansible-config CLI to allow for listing config options and dumping current config (including origin)
   - TODO: build upon this to add many features detailed in ansible-config proposal https://github.com/ansible/proposals/issues/35
 * Windows modules now support the use of multiple shared module_utils files in the form of Powershell modules (.psm1), via `#Requires -Module Ansible.ModuleUtils.Whatever.psm1`
 * Python module argument_spec now supports custom validation logic by accepting a callable as the `type` argument.
 * Windows become_method: runas now works across all authtypes and will auto-elevate under UAC if WinRM user has "Act as part of the operating system" privilege
+* Do not escape backslashes in the template lookup plugin to mirror what the template module does
+  https://github.com/ansible/ansible/issues/26397
 
 ### Deprecations
 * The behaviour when specifying `--tags` (or `--skip-tags`) multiple times on the command line
@@ -49,33 +664,36 @@ Ansible Changes By Release
   moved to `ansible.utils.unsafe_proxy` to avoid a circular import.
 * The win_get_url module has the dictionary 'win_get_url' in its results deprecated,
   its content is now also available directly in the resulting output, like other modules.
+* previouslly deprecated 'hostfile' config settings have been 're-deprecated' as before the code did not warn about deprecated configuration settings
+, but it does now.
 
 #### Deprecated Modules (to be removed in 2.8):
-* ec2_facts: replaced by ec2_metadata_facts
+* azure: use M(azure_rm_virtualmachine) instead
 * cs_nic: replaced by cs_instance_nic_secondaryip, also see new module cs_instance_nic for managing nics
+* ec2_facts: replaced by ec2_metadata_facts
+* ec2_remote_facts: replaced by ec2_instance_facts
 * panos_address: use M(panos_object) instead
-* panos_service: use M(panos_object) instead
-* panos_security_policy: use M(panos_security_rule) instead
 * panos_nat_policy: use M(panos_nat_rule) instead
+* panos_security_policy: use M(panos_security_rule) instead
+* panos_service: use M(panos_object) instead
 * s3: replaced by aws_s3
-* ec2_remote_facts: replaced by 
 * win_msi: use M(win_package) instead
 
-#### Removed Modules (previouslly deprecated):
+#### Removed Modules (previously deprecated):
 * eos_template: use eos_config instead
 * ios_template: use ios_config instead
 * iosxr_template: use iosxr_config instead
 * junos_template: use junos_config instead
 * nxos_template: use nxos_config instead
-* ops_template: use ops_config instead
 * openswitch
+* ops_template: use ops_config instead
 
 
 ### Minor Changes
-* Removed previously deprecated config option `hostfile` and env var `ANSIBLE_HOSTS`
+* Now deprecated configuration options issue warnings when set.
 * Removed unused and deprecated config option `pattern`
 * Updated the copy of six bundled for modules to use from 1.4.1 to 1.10.0
-* The `include_dir` var is not a global anymore, as we now allow multiple inventory sources, it is now host dependant.
+* The `inventory_dir` var is not a global anymore, as we now allow multiple inventory sources, it is now host dependant.
   This means it cannot be used wherever host vars are not permitted, for example in task/handler names.
 * Fixed a cornercase with ini inventory vars.  Previously, if an inventory var
   was a quoted string with hash marks ("#") in it then the parsed string
@@ -130,21 +748,51 @@ Ansible Changes By Release
     - extensions of files to ignore when using inventory directory
 	- patterns of flies to ignore when using inventory directory
 	- option to toggle failed inventory source parsing between an error or a warning
+* More fixes for Python 3 across the code base.
+* win_shell and win_command modules now properly preserve quoted arguments passed on the command-line. Tasks that attempted to work around the issue by adding extra quotes/escaping may need to be reworked. See https://github.com/ansible/ansible/issues/23019 for additional detail.
+* All configuration paths are now relative to the `ansible.cfg` file used.
+* By user request, a 'configuration macro' (``CWD``) is available to force configured paths to be relative to the current working directory. Please note that this is unsafe and not recommended.
+
 
 #### New Callbacks:
 - full_skip
 - profile_roles
 - stderr
 
+#### New Connection plugins:
+- buildah
+- saltstack
+
 #### New Filters:
+- ipaddr filter gained several new suboptions
+  - first_usable
+  - ip/prefix
+  - ip_netmask
+  - last_usable
+  - next_usable
+  - network_id
+  - network/prefix
+  - network_netmask
+  - network_wildcard
+  - previous_usable
+  - range_usable
+  - size_usable
+  - wildcard
+- next_nth_usable
+- network_in_network
+- network_in_usable
+- previous_nth_usable
 - parse_cli
 - parse_cli_textfsm
+- strftime
+- urlsplit
 
 #### New Inventory Plugins:
 - advanced_host_list
 - constructed
 - host_list
 - ini
+- openstack
 - script
 - virtualbox
 - yaml
@@ -152,11 +800,22 @@ Ansible Changes By Release
 #### New Inventory scripts:
 - lxd
 
-#### New: Tests
+#### New Lookups:
+- chef_databag
+- cyberarkpassword
+- hiera
+
+#### New Tests:
 - any : true if any element is true
 - all: true if all elements are true
 
 ### Module Notes
+- By mistake, an early version of elb_classic_lb, elb_instance, and elb_classic_lb_facts modules
+  were released and marked as stableinterface.  These are now marked as preview in 2.4.1 and their
+  parameters and return values may change in 2.5.0.  Part of this mistake included deprecating the
+  ec2_elb_lb, ec2_lb, and ec2_elb_facts modules prematurely.  These modules won't be deprecated
+  until the replacements above have a stableinterface and the erroneous deprecation has been fixed
+  in 2.4.1.
 - The docker_container module has gained a new option, `working_dir` which allows
   specifying the working directory for the command being run in the image.
 - The ec2_win_password module now requires the cryptography python module be installed to run
@@ -578,6 +1237,140 @@ Ansible Changes By Release
   * win_wait_for
   * win_wakeonlan
 
+<a id="2.3.3"></a>
+
+## 2.3.3 "Ramble On" - TBD
+
+### Bugfixes
+* Fix alternatives module handlling of non existing options
+* Fix synchronize traceback with the docker connection plugin
+* Fix the expires option of the postgresq_user module
+* Fix for win_acl when settings permissions on registry objects that use `ALL APPLICATION PACKAGES` and `ALL RESTRICTED APPLICATION PACKAGES`
+* Python3 fixes
+  * asorted azure modules
+  * pause module
+  * hacking/env-setup script
+  * Fix traceback when checking for passwords in logged strings when logging executed commands.
+  * docker_login module
+  * Workaround python-libselinux API change in the seboolean module
+  * digital_ocean_tag module
+  * Fix the zip filter
+  * Fix user module combining bytes and text
+  * Fix for security groups in the amazon efs module
+  * Fix for the jail connection plugin not finding the named jail
+  * Fix for blockinfile's parameters insertbefore and insertafter
+* ios_config: Fix traceback when the efaults parameter is not set
+* iosxr_config: Fixed unicode error when UTF-8 characters are in configs
+* Fix check mode in archive module
+* Fix UnboundLocalError in check mode in cs_role module
+* Fix to always use lowercase hostnames for host keys in known_hosts module
+* Added missing return results for win_stat
+* Fix rabbitmq modules to give a helpful error if requests is not installed
+* Fix yum module not deleting rpms that it downloaded
+* Fix yum module failing with a URL to an rpm
+* Fix file module inappropriately expanding literal dollar signs in a path read
+  from the filesystem as an environment variable.
+* Fix the ssh "smart" transport setting which automatically selects the best means of
+  transferring files over ssh (sftp, ssh, piped).
+* Fix authentication by api_key parameter in exoscale modules.
+* vmware module_utils shared code ssl/validate_certs fixes in connection logic
+* allow 'bridge' facts to work for certain containers that create conflicting ones with connection plugins
+* Fix for win_get_url to use TLS 1.2/1.1 if it is available on the host
+* Fix for the filetree lookup with non-ascii group names
+* Better message for invalid keywords/options in task due to undefined expressions
+* Fixed check mode for enable on Solaris for service module
+* Fix cloudtrail module to allow AWS profiles other than the default
+* Fix an encoding issue with secret (password) vars_prompts
+
+<a id="2.3.2"></a>
+
+## 2.3.2 "Ramble On" - 2017-08-04
+
+### Bugfixes
+* Fix partend i18n issues
+* fixed handling of extra vars for tower_job_template (#25272)
+* Python3 bugfixes
+  * Fix sorting of ec2 policies
+  * Fix digital_ocean dynamic inventory script
+  * Fix for the docker connection plugin
+  * Fix pip module when using python3's pyvenv and python3 -m venv to create virtualenvs
+* Fix for the AnsiBallZ wrapper so that it gives a better error message when
+  there's not enough disk space to create its tempdir.
+* Fix so ansilbe-galaxy install --force with unversioned roles will once again
+  overwrite old versions.
+* Fix for RabbitMQ 3.6.7 endpoint return code changing.
+* Fix for Foreman organization creation
+* fixed incorrect fail_json ref in rpm_key
+* Corrected requried on hash_name for dynamodb_table
+* Fix for fetch action plugin not validating correctly
+* Avoid vault view writing display to logs
+* htpasswd: fix passlib module version comparison
+* Fix for flowdock error message when external_user_name is missing
+* fixed corner case for delegate_to, loops and delegate_facts
+* fixed wait_for python2.4/2.5 compatibility (this is last version this is needed)
+* fix for adhoc not obeying callback options
+* fix for win_find where it fails to recursively scan empty nested directories
+* fix non-pipelined code paths for Windows (eg, ANSIBLE_KEEP_REMOTE_FILES, non-pipelined connection plugins)
+* fix for win_updates where args and check mode were ignored due to common code change
+* fix for unprivileged users to Windows runas become method
+* fix starttls code path for mail module
+* fix missing LC_TYPE in parted module
+* fix CN parsing with OpenSSL 1.1 in letsencrypt module
+* fix params assignment in jabber module
+* fix TXT record type handling in exo_dns_record module
+* fix message queue message ttl can't be 0 in rabbitmq_queue module
+* CloudStack bugfixes:
+  * fix template upload for users in cs_template module, change default to is_routing=None
+  * several fixes in cs_host module fixes hypervisor handling
+  * fix network param ignored due typo in cs_nic module
+  * fix missing type bool in module cs_zone
+  * fix KeyError: 'sshkeypair' in cs_instance module for CloudStack v4.5 and before
+* fix for win_chocolatey where trying to upgrade all the packages as per the example docs fails
+* fix for win_chocolatey where it did not fail if the version set did not exist
+* fix for win_regedit always changing a reg key if the dword values set is a hex
+* fix for wait_for on non-Linux systems with newer versions of psutil
+* fix eos_banner code and test issues
+* run tearup and teardown of EAPI service only on EAPI tests
+* fix eos_config tests so only Eth1 and Eth2 are used
+* Fix for potential bug when using legacy inventory vars for configuring the su password.
+* Fix crash in file module when directories contain non-utf8 filenames
+* Fix for dnf groupinstall with dnf-2.x
+* Fix seboolean module for incompatibility in newer Python3 selinux bindings
+* Optimization for inventory, no need to dedup at every stage, its redundant and slow
+* Fix fact gathering for package and service action plugins
+* make random_choice more error resilient (#27380)
+* ensure prefix in plugin loading to avoid conflicts
+* fix for a small number of modules (tempfile, possibly copy) which could fail
+  if the tempdir on the remote box was a symlink
++ fix non-pipelined code paths for Windows (eg, ANSIBLE_KEEP_REMOTE_FILES, non-pipelined connection plugins)
+* fix for win_updates where args and check mode were ignored due to common code change
+
+<a id="2.3.1"></a>
+
+## 2.3.1 "Ramble On" - 2017-06-01
+
+
+### Bugfixes
+* Security fix for CVE-2017-7481 - data for lookup plugins used as variables was not being correctly marked as "unsafe".
+* Fix default value of fetch module's validate_checksum to be True
+* Added fix for "meta: refresh_connection" not working with default 'smart' connection.
+* Fix template so that the --diff command line option works when the destination is a directory
+* Fix python3 bugs in pam_limits
+* Fix unbound error when using module deprecation as a single string
+* Several places in which error handling was broken due to bad conversions or just typos
+* Fix to user module for appending/setting groups on OpenBSD (flags were reversed)
+* assemble fix to use safer os.join.path, avoids charset issues
+* fixed issue with solaris facts and i18n
+* added python2.4 compatiblity fix to sysctl module
+* Fix comparison of exisiting container security opts in the docker_container module
+* fixed service module invocation of insserv on certain platforms
+* Fix traceback in os_user in an error case.
+* Fix docker container to restart a container when changing to fewer exposed ports
+* Fix tracebacks in docker_network
+* Fixes to detection of updated docker images
+* Handle detection of docker image changes when published ports is changed
+* Fix for docker_container restarting images when links list is empty.
+
 <a id="2.3"></a>
 
 ## 2.3 "Ramble On" - 2017-04-12
@@ -613,6 +1406,7 @@ Moving to Ansible 2.3 guide http://docs.ansible.com/ansible/porting_guide_2.3.ht
 * 'service' tasks can now use async again, we had lost this capability when changed into an action plugin.
 * made any_errors_fatal inheritable from play to task and all other objects in between.
 * many small performance improvements in inventory and variable handling and in task execution.
+* Added a retry class to the ec2_asg module since customers were running into throttling errors (AWSRetry is a solution for modules using boto3 which isn't applicable here).
 
 ### Deprecations
 * Specifying --tags (or --skip-tags) multiple times on the command line
@@ -844,6 +1638,14 @@ Moving to Ansible 2.3 guide http://docs.ansible.com/ansible/porting_guide_2.3.ht
   * panos_service
 - postgresql_schema
 - proxmox_kvm
+- proxysql:
+  * proxysql_backend_servers
+  * proxysql_global_variables
+  * proxysql_manage_config
+  * proxysql_mysql_users
+  * proxysql_query_rules
+  * proxysql_replication_hostgroups
+  * proxysql_scheduler
 - pubnub_blocks
 - pulp_repo
 - runit
@@ -1640,7 +2442,7 @@ Module fixes:
   This re-executes inventory scripts, but does not force them to ignore any cache they might use.
 * New delegate_facts directive, a boolean that allows you to apply facts to the delegated host (true/yes) instead of the inventory_hostname (no/false) which is the default and previous behaviour.
 * local connections now work with 'su' as a privilege escalation method
-* Ansible 2.0 has deprecated the “ssh” from ansible_ssh_user, ansible_ssh_host, and ansible_ssh_port to become ansible_user, ansible_host, and ansible_port.
+* Ansible 2.0 has deprecated the "ssh" from ansible_ssh_user, ansible_ssh_host, and ansible_ssh_port to become ansible_user, ansible_host, and ansible_port.
 * New ssh configuration variables (`ansible_ssh_common_args`, `ansible_ssh_extra_args`) can be used to configure a
   per-group or per-host ssh ProxyCommand or set any other ssh options.
   `ansible_ssh_extra_args` is used to set options that are accepted only by ssh (not sftp or scp, which have their own analogous settings).

Makefile

@@ -29,6 +29,7 @@ ASCII2HTMLMAN = a2x -L -D docs/html/man/ -d manpage -f xhtml
 else
 ASCII2MAN = @echo "ERROR: AsciiDoc 'a2x' command is not installed but is required to build $(MANPAGES)" && exit 1
 endif
+GENERATE_CLI = docs/bin/generate_man.py
 
 PYTHON=python
 SITELIB = $(shell $(PYTHON) -c "from distutils.sysconfig import get_python_lib; print get_python_lib()")
@@ -343,8 +344,9 @@ webdocs:
 
 .PHONY: generate_asciidoc
 generate_asciidoc: lib/ansible/cli/*.py
-	mkdir -p ./docs/man/man1/
-	PYTHONPATH=./lib ./docs/bin/generate_man.py
+	mkdir -p ./docs/man/man1/ ; \
+	PYTHONPATH=./lib $(GENERATE_CLI) --template-file=docs/templates/man.j2 --output-dir=docs/man/man1/ --output-format man lib/ansible/cli/*.py
+
 
 docs: generate_asciidoc
 	make $(MANPAGES)

RELEASES.txt

@@ -4,7 +4,20 @@ Ansible Releases at a Glance
 VERSION  RELEASE     CODE NAME
 ++++++++++++++++++++++++++++++
 
-2.4.0    TBD         "Dancing Days"
+2.6.0    TBD         "HeartBreaker"
+2.5.5    14-06-2018  "Kashmir"
+2.5.4    31-05-2018  "Kashmir"
+2.5.3    17-05-2018  "Kashmir"
+2.5.2    26-04-2018  "Kashmir"
+2.5.1    19-04-2018  "Kashmir"
+2.5.0    23-03-2018  "Kashmir"
+2.4.6    07-05-2018  "Dancing Days"
+2.4.5    06-21-2018  "Dancing Days"
+2.4.4    04-04-2018  "Dancing Days"
+2.4.3    01-31.2018  "Dancing Days"
+2.4.2    11-29-2017  "Dancing Days"
+2.4.1    10-25-2017  "Dancing Days"
+2.4.0    09-19-2017  "Dancing Days"
 2.3.2    08-04-2017  "Ramble On"
 2.3.1    06-01-2017  "Ramble On"
 2.3.0    04-12-2017  "Ramble On"

VERSION

@@ -1 +1 @@
-2.4.0 0.0.devel
+2.4.6.0 1

bin/ansible-connection

@@ -214,7 +214,6 @@ class Server():
 
     def do_EXEC(self, data):
         cmd = data.split(b'EXEC: ')[1]
-        display.display('Command executed: %s' % cmd, log_only=True)
         return self.connection.exec_command(cmd)
 
     def do_PUT(self, data):

contrib/inventory/azure_rm.py

@@ -187,14 +187,18 @@ Version: 1.0.0
 '''
 
 import argparse
-import ConfigParser
 import json
 import os
 import re
 import sys
 import inspect
-import traceback
 
+try:
+    # python2
+    import ConfigParser as cp
+except ImportError:
+    # python3
+    import configparser as cp
 
 from packaging.version import Version
 
@@ -326,7 +330,7 @@ class AzureRM(object):
         path = expanduser("~")
         path += "/.azure/credentials"
         try:
-            config = ConfigParser.ConfigParser()
+            config = cp.ConfigParser()
             config.read(path)
         except Exception as exc:
             self.fail("Failed to access {0}. Check that the file exists and you have read "
@@ -795,7 +799,7 @@ class AzureInventory(object):
         config = None
         settings = None
         try:
-            config = ConfigParser.ConfigParser()
+            config = cp.ConfigParser()
             config.read(path)
         except:
             pass

contrib/inventory/consul_io.py

@@ -473,10 +473,7 @@ class ConsulConfig(dict):
         scheme = 'http'
 
         if hasattr(self, 'url'):
-            try:
-                from urlparse import urlparse
-            except ImportError:
-                from urllib.parse import urlparse
+            from ansible.module_utils.six.moves.urllib.parse import urlparse
             o = urlparse(self.url)
             if o.hostname:
                 host = o.hostname

contrib/inventory/docker.py

@@ -371,7 +371,6 @@ HAS_DOCKER_PY = True
 HAS_DOCKER_ERROR = False
 
 try:
-    from docker import Client
     from docker.errors import APIError, TLSParameterError
     from docker.tls import TLSConfig
     from docker.constants import DEFAULT_TIMEOUT_SECONDS, DEFAULT_DOCKER_API_VERSION
@@ -379,6 +378,19 @@ except ImportError as exc:
     HAS_DOCKER_ERROR = str(exc)
     HAS_DOCKER_PY = False
 
+# Client has recently been split into DockerClient and APIClient
+try:
+    from docker import Client
+except ImportError as exc:
+    try:
+        from docker import APIClient as Client
+    except ImportError as exc:
+        HAS_DOCKER_ERROR = str(exc)
+        HAS_DOCKER_PY = False
+
+        class Client:
+            pass
+
 DEFAULT_DOCKER_HOST = 'unix://var/run/docker.sock'
 DEFAULT_TLS = False
 DEFAULT_TLS_VERIFY = False
@@ -779,6 +791,10 @@ class DockerInventory(object):
         if config_path:
             try:
                 config_file = os.path.abspath(config_path)
+                # default config path is docker.yml in same directory as this script
+                # old behaviour is docker.yml in current directory. Handle both.
+                if not os.path.exists(config_file):
+                    config_file = os.path.abspath(os.path.basename(config_path))
             except:
                 config_file = None
 
@@ -813,7 +829,7 @@ class DockerInventory(object):
         # Parse command line arguments
 
         basename = os.path.splitext(os.path.basename(__file__))[0]
-        default_config = basename + '.yml'
+        default_config = os.path.join(os.path.dirname(__file__), basename + '.yml')
 
         parser = argparse.ArgumentParser(
             description='Return Ansible inventory for one or more Docker hosts.')

contrib/inventory/rudder.py

@@ -56,12 +56,8 @@ import argparse
 import six
 import httplib2 as http
 from time import time
-from six.moves import configparser
-
-try:
-    from urlparse import urlparse
-except ImportError:
-    from urllib.parse import urlparse
+from ansible.module_utils.six.moves import configparser
+from ansible.module_utils.six.moves.urllib.parse import urlparse
 
 try:
     import json

contrib/inventory/vagrant.py

@@ -38,14 +38,17 @@ import os.path
 import subprocess
 import re
 from paramiko import SSHConfig
-from cStringIO import StringIO
 from optparse import OptionParser
 from collections import defaultdict
 try:
     import json
-except:
+except Exception:
     import simplejson as json
 
+from ansible.module_utils._text import to_text
+from ansible.module_utils.six.moves import StringIO
+
+
 _group = 'vagrant'  # a default group
 _ssh_to_ansible = [('user', 'ansible_ssh_user'),
                    ('hostname', 'ansible_ssh_host'),
@@ -74,7 +77,8 @@ def get_ssh_config():
 
 # list all the running boxes
 def list_running_boxes():
-    output = subprocess.check_output(["vagrant", "status"]).split('\n')
+
+    output = to_text(subprocess.check_output(["vagrant", "status"]), errors='surrogate_or_strict').split('\n')
 
     boxes = []
 
@@ -90,7 +94,7 @@ def list_running_boxes():
 def get_a_ssh_config(box_name):
     """Gives back a map of all the machine's ssh configurations"""
 
-    output = subprocess.check_output(["vagrant", "ssh-config", box_name])
+    output = to_text(subprocess.check_output(["vagrant", "ssh-config", box_name]), errors='surrogate_or_strict')
     config = SSHConfig()
     config.parse(StringIO(output))
     host_config = config.lookup(box_name)
@@ -104,6 +108,7 @@ def get_a_ssh_config(box_name):
 
     return dict((v, host_config[k]) for k, v in _ssh_to_ansible)
 
+
 # List out servers that vagrant has running
 # ------------------------------
 if options.list:

contrib/inventory/windows_azure.py

@@ -39,7 +39,7 @@ import re
 import sys
 import argparse
 import os
-from urlparse import urlparse
+from ansible.module_utils.six.moves.urllib.parse import urlparse
 from time import time
 try:
     import json

docs/bin/dump_keywords.py

@@ -1,8 +1,11 @@
 #!/usr/bin/env python
 
 import optparse
-import yaml
+import re
+from distutils.version import LooseVersion
 
+import jinja2
+import yaml
 from jinja2 import Environment, FileSystemLoader
 
 from ansible.playbook import Play
@@ -18,7 +21,7 @@ class_list = [Play, Role, Block, Task]
 p = optparse.OptionParser(
     version='%prog 1.0',
     usage='usage: %prog [options]',
-    description='Generate module documentation from metadata',
+    description='Generate playbook keyword documentation from code and descriptions',
 )
 p.add_option("-T", "--template-dir", action="store", dest="template_dir", default="../templates", help="directory containing Jinja2 templates")
 p.add_option("-o", "--output-dir", action="store", dest="output_dir", default='/tmp/', help="Output directory for rst files")
@@ -65,5 +68,10 @@ template = env.get_template(template_file)
 outputname = options.output_dir + template_file.replace('.j2', '')
 tempvars = {'oblist': oblist, 'clist': clist}
 
+keyword_page = template.render(tempvars)
+if LooseVersion(jinja2.__version__) < LooseVersion('2.10'):
+    # jinja2 < 2.10's indent filter indents blank lines.  Cleanup
+    keyword_page = re.sub(' +\n', '\n', keyword_page)
+
 with open(outputname, 'w') as f:
-    f.write(template.render(tempvars))
+    f.write(keyword_page)

docs/bin/generate_man.py

@@ -1,6 +1,8 @@
 #!/usr/bin/env python
 
+import optparse
 import os
+import pprint
 import sys
 
 from jinja2 import Environment, FileSystemLoader
@@ -8,6 +10,46 @@ from jinja2 import Environment, FileSystemLoader
 from ansible.module_utils._text import to_bytes
 
 
+def generate_parser():
+    p = optparse.OptionParser(
+        version='%prog 1.0',
+        usage='usage: %prog [options]',
+        description='Generate cli documentation from cli docstrings',
+    )
+
+    p.add_option("-t", "--template-file", action="store", dest="template_file", default="../templates/man.j2", help="path to jinja2 template")
+    p.add_option("-o", "--output-dir", action="store", dest="output_dir", default='/tmp/', help="Output directory for rst files")
+    p.add_option("-f", "--output-format", action="store", dest="output_format", default='man', help="Output format for docs (the default 'man' or 'rst')")
+    return p
+
+
+# from https://www.python.org/dev/peps/pep-0257/
+def trim_docstring(docstring):
+    if not docstring:
+        return ''
+    # Convert tabs to spaces (following the normal Python rules)
+    # and split into a list of lines:
+    lines = docstring.expandtabs().splitlines()
+    # Determine minimum indentation (first line doesn't count):
+    indent = sys.maxint
+    for line in lines[1:]:
+        stripped = line.lstrip()
+        if stripped:
+            indent = min(indent, len(line) - len(stripped))
+    # Remove indentation (first line is special):
+    trimmed = [lines[0].strip()]
+    if indent < sys.maxint:
+        for line in lines[1:]:
+            trimmed.append(line[indent:].rstrip())
+    # Strip off trailing and leading blank lines:
+    while trimmed and not trimmed[-1]:
+        trimmed.pop()
+    while trimmed and not trimmed[0]:
+        trimmed.pop(0)
+    # Return a single string:
+    return '\n'.join(trimmed)
+
+
 def get_options(optlist):
     ''' get actual options '''
 
@@ -24,107 +66,215 @@ def get_options(optlist):
     return opts
 
 
+def get_option_groups(option_parser):
+    groups = []
+    for option_group in option_parser.option_groups:
+        group_info = {}
+        group_info['desc'] = option_group.get_description()
+        group_info['options'] = option_group.option_list
+        group_info['group_obj'] = option_group
+        groups.append(group_info)
+    return groups
+
+
 def opt_doc_list(cli):
     ''' iterate over options lists '''
 
     results = []
-    for optg in cli.parser.option_groups:
-        results.extend(get_options(optg.option_list))
+    for option_group in cli.parser.option_groups:
+        results.extend(get_options(option_group.option_list))
 
     results.extend(get_options(cli.parser.option_list))
 
     return results
 
 
-def opts_docs(cli, name):
+# def opts_docs(cli, name):
+def opts_docs(cli_class_name, cli_module_name):
     ''' generate doc structure from options '''
 
-    # cli name
-    if '-' in name:
-        name = name.split('-')[1]
-    else:
-        name = 'adhoc'
+    cli_name = 'ansible-%s' % cli_module_name
+    if cli_module_name == 'adhoc':
+        cli_name = 'ansible'
 
-    # cli info
+    # WIth no action/subcommand
+    # shared opts set
+    # instantiate each cli and ask its options
+    cli_klass = getattr(__import__("ansible.cli.%s" % cli_module_name,
+                                   fromlist=[cli_class_name]), cli_class_name)
+    cli = cli_klass([])
+
+    # parse the common options
+    try:
+        cli.parse()
+    except:
+        pass
+
+    # base/common cli info
     docs = {
-        'cli': name,
+        'cli': cli_module_name,
+        'cli_name': cli_name,
         'usage': cli.parser.usage,
         'short_desc': cli.parser.description,
-        'long_desc': cli.__doc__,
+        'long_desc': trim_docstring(cli.__doc__),
+        'actions': {},
     }
+    option_info = {'option_names': [],
+                   'options': [],
+                   'groups': []}
 
+    for extras in ('ARGUMENTS'):
+        if hasattr(cli, extras):
+            docs[extras.lower()] = getattr(cli, extras)
+
+    common_opts = opt_doc_list(cli)
+    groups_info = get_option_groups(cli.parser)
+    shared_opt_names = []
+    for opt in common_opts:
+        shared_opt_names.extend(opt.get('options', []))
+
+    option_info['options'] = common_opts
+    option_info['option_names'] = shared_opt_names
+
+    option_info['groups'].extend(groups_info)
+
+    docs.update(option_info)
+
+    # now for each action/subcommand
     # force populate parser with per action options
-    if cli.VALID_ACTIONS:
-        docs['actions'] = {}
+
+    # use class attrs not the attrs on a instance (not that it matters here...)
+    for action in getattr(cli_klass, 'VALID_ACTIONS', ()):
+        # instantiate each cli and ask its options
+        action_cli_klass = getattr(__import__("ansible.cli.%s" % cli_module_name,
+                                              fromlist=[cli_class_name]), cli_class_name)
+        # init with args with action added?
+        cli = action_cli_klass([])
+        cli.args.append(action)
+
+        try:
+            cli.parse()
+        except:
+            pass
+
+        # FIXME/TODO: needed?
         # avoid dupe errors
         cli.parser.set_conflict_handler('resolve')
-        for action in cli.VALID_ACTIONS:
-            cli.args.append(action)
-            cli.set_action()
-            docs['actions'][action] = getattr(cli, 'execute_%s' % action).__doc__
+
+        cli.set_action()
+
+        action_info = {'option_names': [],
+                       'options': []}
+        # docs['actions'][action] = {}
+        # docs['actions'][action]['name'] = action
+        action_info['name'] = action
+        action_info['desc'] = trim_docstring(getattr(cli, 'execute_%s' % action).__doc__)
+
+        # docs['actions'][action]['desc'] = getattr(cli, 'execute_%s' % action).__doc__.strip()
+        action_doc_list = opt_doc_list(cli)
+
+        uncommon_options = []
+        for action_doc in action_doc_list:
+            # uncommon_options = []
+
+            option_aliases = action_doc.get('options', [])
+            for option_alias in option_aliases:
+
+                if option_alias in shared_opt_names:
+                    continue
+
+                # TODO: use set
+                if option_alias not in action_info['option_names']:
+                    action_info['option_names'].append(option_alias)
+
+                if action_doc in action_info['options']:
+                    continue
+
+                uncommon_options.append(action_doc)
+
+            action_info['options'] = uncommon_options
+
+        docs['actions'][action] = action_info
 
     docs['options'] = opt_doc_list(cli)
-
     return docs
 
+
 if __name__ == '__main__':
 
-    template_file = 'man.j2'
+    parser = generate_parser()
 
+    options, args = parser.parse_args()
+
+    template_file = options.template_file
+    template_path = os.path.expanduser(template_file)
+    template_dir = os.path.abspath(os.path.dirname(template_path))
+    template_basename = os.path.basename(template_file)
+
+    output_dir = os.path.abspath(options.output_dir)
+    output_format = options.output_format
+
+    cli_modules = args
+
+    # various cli parsing things checks sys.argv if the 'args' that are passed in are []
+    # so just remove any args so the cli modules dont try to parse them resulting in warnings
+    sys.argv = [sys.argv[0]]
     # need to be in right dir
     os.chdir(os.path.dirname(__file__))
 
     allvars = {}
     output = {}
     cli_list = []
-    for binary in os.listdir('../../lib/ansible/cli'):
+    cli_bin_name_list = []
+
+    # for binary in os.listdir('../../lib/ansible/cli'):
+    for cli_module_name in cli_modules:
+        binary = os.path.basename(os.path.expanduser(cli_module_name))
 
         if not binary.endswith('.py'):
             continue
         elif binary == '__init__.py':
             continue
 
-        libname = os.path.splitext(binary)[0]
-        print("Found CLI %s" % libname)
+        cli_name = os.path.splitext(binary)[0]
 
-        if libname == 'adhoc':
-            myclass = 'AdHocCLI'
-            output[libname] = 'ansible.1.asciidoc.in'
+        if cli_name == 'adhoc':
+            cli_class_name = 'AdHocCLI'
+            # myclass = 'AdHocCLI'
+            output[cli_name] = 'ansible.1.asciidoc.in'
+            cli_bin_name = 'ansible'
         else:
-            myclass = "%sCLI" % libname.capitalize()
-            output[libname] = 'ansible-%s.1.asciidoc.in' % libname
+            # myclass = "%sCLI" % libname.capitalize()
+            cli_class_name = "%sCLI" % cli_name.capitalize()
+            output[cli_name] = 'ansible-%s.1.asciidoc.in' % cli_name
+            cli_bin_name = 'ansible-%s' % cli_name
 
-        # instantiate each cli and ask its options
-        mycli = getattr(__import__("ansible.cli.%s" % libname, fromlist=[myclass]), myclass)
-        cli_object = mycli([])
-        try:
-            cli_object.parse()
-        except:
-            # no options passed, we expect errors
-            pass
-
-        allvars[libname] = opts_docs(cli_object, libname)
-
-        for extras in ('ARGUMENTS'):
-            if hasattr(cli_object, extras):
-                allvars[libname][extras.lower()] = getattr(cli_object, extras)
+        # FIXME:
+        allvars[cli_name] = opts_docs(cli_class_name, cli_name)
+        cli_bin_name_list.append(cli_bin_name)
 
     cli_list = allvars.keys()
-    for libname in cli_list:
+
+    doc_name_formats = {'man': '%s.1.asciidoc.in',
+                        'rst': '%s.rst'}
+
+    for cli_name in cli_list:
 
         # template it!
-        env = Environment(loader=FileSystemLoader('../templates'))
-        template = env.get_template('man.j2')
+        env = Environment(loader=FileSystemLoader(template_dir))
+        template = env.get_template(template_basename)
 
         # add rest to vars
-        tvars = allvars[libname]
+        tvars = allvars[cli_name]
         tvars['cli_list'] = cli_list
-        tvars['cli'] = libname
+        tvars['cli_bin_name_list'] = cli_bin_name_list
+        tvars['cli'] = cli_name
         if '-i' in tvars['options']:
             print('uses inventory')
 
         manpage = template.render(tvars)
-        filename = '../man/man1/%s' % output[libname]
+        filename = os.path.join(output_dir, doc_name_formats[output_format] % tvars['cli_name'])
+
         with open(filename, 'wb') as f:
             f.write(to_bytes(manpage))
-            print("Wrote man docs to %s" % filename)
+            print("Wrote doc to %s" % filename)

docs/bin/plugin_formatter.py

@@ -30,6 +30,9 @@ import re
 import sys
 import warnings
 from collections import defaultdict
+from distutils.version import LooseVersion
+from pprint import PrettyPrinter
+
 try:
     from html import escape as html_escape
 except ImportError:
@@ -39,6 +42,7 @@ except ImportError:
     def html_escape(text, quote=True):
         return cgi.escape(text, quote)
 
+import jinja2
 import yaml
 from jinja2 import Environment, FileSystemLoader
 from six import iteritems
@@ -120,6 +124,9 @@ def write_data(text, output_dir, outputname, module=None):
     if output_dir is not None:
         if module:
             outputname = outputname % module
+
+        if not os.path.exists(output_dir):
+            os.makedirs(output_dir)
         fname = os.path.join(output_dir, outputname)
         fname = fname.replace(".py", "")
         with open(fname, 'wb') as f:
@@ -379,6 +386,9 @@ def process_modules(module_map, templates, outputname, output_dir, ansible_versi
             doc['returndocs'] = None
 
         text = templates['plugin'].render(doc)
+        if LooseVersion(jinja2.__version__) < LooseVersion('2.10'):
+            # jinja2 < 2.10's indent filter indents blank lines.  Cleanup
+            text = re.sub(' +\n', '\n', text)
 
         write_data(text, output_dir, outputname, module)
 

docs/docsite/Makefile

@@ -4,6 +4,7 @@ FORMATTER=../bin/plugin_formatter.py
 TESTING_FORMATTER=../bin/testing_formatter.sh
 DUMPER=../bin/dump_keywords.py
 CONFIG_DUMPER=../bin/dump_config.py
+GENERATE_CLI=../bin/generate_man.py
 ifeq ($(shell echo $(OS) | egrep -ic 'Darwin|FreeBSD|OpenBSD|DragonFly'),1)
 CPUS ?= $(shell sysctl hw.ncpu|awk '{print $$2}')
 else
@@ -19,7 +20,8 @@ all: docs
 
 docs: clean htmldocs
 
-htmldocs: testing keywords modules staticmin config
+htmldocs: testing keywords modules staticmin cli config
+
 	CPUS=$(CPUS) $(MAKE) -f Makefile.sphinx html
 
 webdocs: docs
@@ -45,9 +47,14 @@ clean:
 	-rm rst/*_maintained.rst
 	-rm rst/playbooks_directives.rst
 	-rm rst/playbooks_keywords.rst
+#	-rm rst/cli/ansible*.rst
 
 .PHONEY: docs clean
 
+# TODO: make generate_man output dir cli option
+cli: $(GENERATE_CLI)
+	PYTHONPATH=../../lib $(GENERATE_CLI) --template-file=../templates/cli_rst.j2 --output-dir=rst/ --output-format rst ../../lib/ansible/cli/*.py
+
 keywords: $(FORMATTER) ../templates/playbooks_keywords.rst.j2
 	PYTHONPATH=../../lib $(DUMPER) --template-dir=../templates --output-dir=rst/ -d ./keyword_desc.yml
 
@@ -57,7 +64,7 @@ config:
 modules: $(FORMATTER) ../templates/plugin.rst.j2
 # Limit building of module documentation if requested.
 ifdef MODULES
-	PYTHONPATH=../../lib $(FORMATTER) -t rst --template-dir=../templates --module-dir=../../lib/ansible/modules -o rst/ -l $(MODULES)	
+	PYTHONPATH=../../lib $(FORMATTER) -t rst --template-dir=../templates --module-dir=../../lib/ansible/modules -o rst/ -l $(MODULES)
 else
 	PYTHONPATH=../../lib $(FORMATTER) -t rst --template-dir=../templates --module-dir=../../lib/ansible/modules -o rst/
 endif

docs/docsite/_themes/srtd/ansible_eol_banner.html

@@ -0,0 +1,4 @@
+{# Creates a banner at the top of the page for EOL versions. #}
+<div id='banner' class='Admonition caution'>
+  <p>You are reading an unmaintained version of the Ansible documentation. Unmaintained Ansible versions can contain unfixed security vulnerabilities (CVE). Please upgrade to a maintained version. See <a href="https://docs.ansible.com/ansible/latest/index.html">the latest Ansible documentation</a>.</p>
+</div>

docs/docsite/_themes/srtd/layout.html

@@ -33,6 +33,7 @@
   {% if favicon %}
     <link rel="shortcut icon" href="{{ pathto('_static/' + favicon, 1) }}"/>
   {% endif %}
+  <link rel="canonical" href="https://docs.ansible.com/ansible/latest/{{ pagename }}.html"/>
 
   {# CSS #}
   <link href='https://fonts.googleapis.com/css?family=Lato:400,700|Roboto+Slab:400,700|Inconsolata:400,700' rel='stylesheet' type='text/css'>
@@ -158,14 +159,14 @@
         <a class="DocSiteProduct-header DocSiteProduct-header--core" href="/">
             <div class="DocSiteProduct-productName">
                 <div class="DocSiteProduct-logoText">
-                    Ansible  
+                    Ansible
                     <div class="DocSiteProduct-CurrentVersion" align="right">
-                      devel
+                      v2.4
                   </div>
                 </div>
             </div>
         </a>
-        
+
 
           <div class="DocSiteProduct-CheckVersionPara">For previous versions, see the  <a class="DocSiteProduct-versionheader" href="/#coreversionselect">documentation archive.</a></div>
       </div>
@@ -228,6 +229,7 @@
         </div> -->
 
           {% include "breadcrumbs.html" %}
+          {% include "ansible_eol_banner.html" %}
           <div id="page-content">
           {% block body %}{% endblock %}
           </div>

docs/docsite/keyword_desc.yml

@@ -1,55 +1,72 @@
-accelerate: DEPRECATED, set to True to use accelerate connection plugin.
-accelerate_ipv6: DEPRECATED, set to True to force accelerate plugin to use ipv6 for it's connection.
-accelerate_port: DEPRECATED, set to override default port use for accelerate connection.
-action: The 'action' to execute for a task, it normally translates into a C(module) or action plugin.
-args: DEPRECATED, A secondary way to add arguments into a task, it takes a dictionary in which keys map to options and values .. well you get it.
+accelerate: "*DEPRECATED*, set to True to use accelerate connection plugin."
+accelerate_ipv6: "*DEPRECATED*, set to True to force accelerate plugin to use ipv6 for its connection."
+accelerate_port: "*DEPRECATED*, set to override default port use for accelerate connection."
+action: "The 'action' to execute for a task, it normally translates into a C(module) or action plugin."
+args: "*DEPRECATED*, A secondary way to add arguments into a task. Takes a dictionary in which keys map to options and values."
 always: List of tasks, in a block, that execute no matter if there is an error in the block or not.
-always_run: DEPRECATED, forces a task to run even in check mode, use check_mode directive instead.
+always_run: "*DEPRECATED*, forces a task to run even in check mode. Use :term:`check_mode` directive instead."
 any_errors_fatal: Force any un-handled task errors on any host to propagate to all hosts and end the play.
 async: Run a task asyncronouslly if the C(action) supports this.
-become: Boolean that controls if privilege escalation is used or not on Task execution.
-become_flags: A string of flag(s) to pass to the privilege escalation program when ``become`` is True.
-become_method: Which method of privilege escalation to use. i.e. sudo/su/etc.
-become_user: User that you 'become' after using privilege escalation, the remote/login user must have permissions to become this user.
+become: Boolean that controls if privilege escalation is used or not on :term:`Task` execution.
+become_flags: A string of flag(s) to pass to the privilege escalation program when :term:`become` is True.
+become_method: Which method of privilege escalation to use (such as sudo or su).
+become_user: "User that you 'become' after using privilege escalation. The remote/login user must have permissions to become this user."
 block: List of tasks in a block.
-changed_when: Conditional expression that overrides the task's normal 'changed' status.
-check_mode: A boolean that controls if a task is executed in 'check' mode
-connection: Allows you to change the connection plugin used for tasks to execute on the target.
-delay: Number of seconds to delay between retries, this setting only makes sense when used with 'until'.
-delegate_facts: Boolean that allows you to apply facts to delegated host instead of inventory_hostname.
-delegate_to: Host to execute task instead of the target (inventory_hostname), connection vars from the delegated host will also be used for the task.
-diff: Toggle to make tasks return 'diff' information or not.
+changed_when: "Conditional expression that overrides the task's normal 'changed' status."
+check_mode: |
+    A boolean that controls if a task is executed in 'check' mode
+
+    .. seealso:: :ref:`check_mode_dry`
+
+connection: |
+    Allows you to change the connection plugin used for tasks to execute on the target.
+
+    .. seealso:: :ref:`using_connection`
+
+delay: Number of seconds to delay between retries. This setting is only used in combination with :term:`until`.
+delegate_facts: Boolean that allows you to apply facts to a delegated host instead of inventory_hostname.
+delegate_to: Host to execute task instead of the target (inventory_hostname). Connection vars from the delegated host will also be used for the task.
+diff: "Toggle to make tasks return 'diff' information or not."
 environment: A dictionary that gets converted into environment vars to be provided for the task upon execution.
-fact_path: Set the fact path option for the fact gathering plugin controlled by ``gather_facts``.
-failed_when: Conditional expression that overrides the task's normal 'failed' status.
-force_handlers: Will force notified handler execution for hosts even if they failed during the play, it will not trigger if the play itself fails.
-gather_facts: A boolean that controls if the play will automatically run the 'setup' task to gather facts for the hosts.
-gather_subset: Allows you to pass subset options to the  fact gathering plugin controlled by ``gather_facts``.
-gather_timeout: Allows you to set the timeout for the fact gathering plugin controlled by ``gather_facts``.
-handlers: A section with tasks that are treated as handlers, these won't get executed normally, only when notified. After each section of tasks is complete.
-hosts: A list of groups, hosts or host pattern that translates into a list of hosts that are the play's target.
+fact_path: Set the fact path option for the fact gathering plugin controlled by :term:`gather_facts`.
+failed_when: "Conditional expression that overrides the task's normal 'failed' status."
+force_handlers: Will force notified handler execution for hosts even if they failed during the play. Will not trigger if the play itself fails.
+gather_facts: "A boolean that controls if the play will automatically run the 'setup' task to gather facts for the hosts."
+gather_subset: Allows you to pass subset options to the  fact gathering plugin controlled by :term:`gather_facts`.
+gather_timeout: Allows you to set the timeout for the fact gathering plugin controlled by :term:`gather_facts`.
+handlers: "A section with tasks that are treated as handlers, these won't get executed normally, only when notified after each section of tasks is complete."
+hosts: "A list of groups, hosts or host pattern that translates into a list of hosts that are the play's target."
 ignore_errors: Boolean that allows you to ignore task failures and continue with play. It does not affect connection errors.
-loop_control: Several keys here allow you to modify/set loop behaviour in a task see http://docs.ansible.com/ansible/latest/playbooks_loops.html#loop-control for details.
+loop: "Takes a list for the task to iterate over, saving each list element into the ``item`` variable (configurable via loop_control)"
+loop_control: |
+    Several keys here allow you to modify/set loop behaviour in a task.
+
+    .. seealso:: :ref:`loop_control`
+
 max_fail_percentage: can be used to abort the run after a given percentage of hosts in the current batch has failed.
-name: It's a name, works mostly for documentation, in the case of tasks/handlers it can be an identifier.
+name: "Identifier. Can be used for documentation, in or tasks/handlers."
 no_log: Boolean that controls information disclosure.
-notify: list of handlers to notify when the task returns a 'changed=True' status.
+notify: "List of handlers to notify when the task returns a 'changed=True' status."
 order: Controls the sorting of hosts as they are used for executing the play. Possible values are inventory (default), sorted, reverse_sorted, reverse_inventory and shuffle.
 poll: Sets the polling interval in seconds for async tasks (default 10s).
 port: Used to override the default port used in a connection.
-post_tasks: A list of tasks to execute after the ``tasks`` section.
-pre_tasks: A list of tasks to execute before ``roles``.
-remote_user: User used to log into the target via the connection plugin. AKA login user.
+post_tasks: A list of tasks to execute after the :term:`tasks` section.
+pre_tasks: A list of tasks to execute before :term:`roles`.
+remote_user: User used to log into the target via the connection plugin.
 register: Name of variable that will contain task status and module return data.
-rescue: List of tasks in a block that run if there is a task error in the main ``block`` list.
-retries: Number of retries before giving up in a 'until' loop, this setting is ignored on it's own.
+rescue: List of tasks in a :term:`block` that run if there is a task error in the main :term:`block` list.
+retries: "Number of retries before giving up in a :term:`until` loop. This setting is only used in combination with :term:`until`."
 roles: List of roles to be imported into the play
 run_once: Boolean that will bypass the host loop, forcing the task to execute on the first host available and will also apply any facts to all active hosts.
-serial: Defines the 'batch' of hosts to execute the current play until the end.
+serial: |
+    Explicitly define how Ansible batches the execution of the current play on the play's target
+
+    .. seealso:: :ref:`rolling_update_batch_size`
+
 strategy: Allows you to choose the connection plugin to use for the play.
 tags: Tags applied to the task or included tasks, this allows selecting subsets of tasks from the command line.
-tasks: Main list of tasks to execute in the play, they run after ``roles`` and before ``post_tasks``.
-until: This keyword implies a 'retry loop' that will go on until the condition supplied here is met or we hit the retry limit.
+tasks: Main list of tasks to execute in the play, they run after :term:`roles` and before :term:`post_tasks`.
+until: "This keyword implies a ':term:`retries` loop' that will go on until the condition supplied here is met or we hit the :term:`retries` limit."
 vars: Dictionary/map of variables
 vars_files: List of files that contain vars to include in the play.
 vars_prompt: list of variables to prompt for.

docs/docsite/rst/become.rst

@@ -8,7 +8,7 @@ Ansible can use existing privilege escalation systems to allow a user to execute
 Become
 ``````
 Ansible allows you to 'become' another user, different from the user that logged into the machine (remote user). This is done using existing
-privilege escalation tools, which you probably already use or have configured, like `sudo`, `su`, `pfexec`, `doas`, `pbrun`, `dzdo`, `ksu` and others.
+privilege escalation tools, which you probably already use or have configured, like `sudo`, `su`, `pfexec`, `doas`, `pbrun`, `dzdo`, `ksu`, and others.
 
 
 .. note:: Before 1.9 Ansible mostly allowed the use of `sudo` and a limited use of `su` to allow a login/remote user to become a different user

docs/docsite/rst/command_line_tools.rst

@@ -0,0 +1,15 @@
+Command Line Tools
+==================
+
+
+.. toctree:: :maxdepth: 1
+
+    ansible
+    ansible-playbook
+    ansible-vault
+    ansible-galaxy
+    ansible-console
+    ansible-config
+    ansible-doc
+    ansible-inventory
+    ansible-pull

docs/docsite/rst/committer_guidelines.rst

@@ -3,7 +3,7 @@ Committers Guidelines (for people with commit rights to Ansible on GitHub)
 
 These are the guidelines for people with commit access to Ansible. Committers are essentially acting as members of the Ansible Core team, although not necessarily as an employee of Ansible and Red Hat. Please read the guidelines before you commit.
 
-These guidelines apply to everyone. At the same time, this ISN’T a process document. So just use good judgement. You’ve been given commit access because we trust your judgement.
+These guidelines apply to everyone. At the same time, this ISN'T a process document. So just use good judgement. You've been given commit access because we trust your judgement.
 
 That said, use the trust wisely. 
 
@@ -19,18 +19,18 @@ Any other new features and changes to high level design should go through the pr
 Our Workflow on GitHub
 ======================
 
-As a committer, you may already know this, but our workflow forms a lot of our team policies. Please ensure you’re aware of the following workflow steps:
+As a committer, you may already know this, but our workflow forms a lot of our team policies. Please ensure you're aware of the following workflow steps:
 
 * Fork the repository upon which you want to do some work to your own personal repository
 * Work on the specific branch upon which you need to commit
-* Create a Pull Request back to the Ansible repository and tag the people you would like to review; assign someone as the primary “owner” of your request
+* Create a Pull Request back to the Ansible repository and tag the people you would like to review; assign someone as the primary "owner" of your request
 * Adjust code as necessary based on the Comments provided
 * Ask someone on the Core Team to do a final review and merge
 
 Addendum to workflow for Committers:
 ------------------------------------
 
-The Core Team is aware that this can be a difficult process at times. Sometimes, the team breaks the rules: Direct commits, merging their own PRs. This section is a set of guidelines. If you’re changing a comma in a doc, or making a very minor change, you can use your best judgement. This is another trust thing. The process is critical for any major change, but for little things or getting something done quickly, use your best judgement and make sure people on the team are aware of your work.
+The Core Team is aware that this can be a difficult process at times. Sometimes, the team breaks the rules: Direct commits, merging their own PRs. This section is a set of guidelines. If you're changing a comma in a doc, or making a very minor change, you can use your best judgement. This is another trust thing. The process is critical for any major change, but for little things or getting something done quickly, use your best judgement and make sure people on the team are aware of your work.
 
 Roles on Core
 =============
@@ -41,12 +41,12 @@ General Rules
 =============
 Individuals with direct commit access to ansible/ansible are entrusted with powers that allow them to do a broad variety of things--probably more than we can write down. Rather than rules, treat these as general *guidelines*, individuals with this power are expected to use their best judgement. 
 
-* Don’t
+* Don't
 
   - Commit directly.
   - Merge your own PRs. Someone else should have a chance to review and approve the PR merge. If you are a Core Committer, you have a small amount of leeway here for very minor changes.
   - Forget about alternate environments. Consider the alternatives--yes, people have bad environments, but they are the ones who need us the most.
-  - Drag your community team members down. Always discuss the technical merits, but you should never address the person’s limitations (you can later go for beers and call them idiots, but not in IRC/Github/etc.).
+  - Drag your community team members down. Always discuss the technical merits, but you should never address the person's limitations (you can later go for beers and call them idiots, but not in IRC/Github/etc.).
   - Forget about the maintenance burden. Some things are really cool to have, but they might not be worth shoehorning in if the maintenance burden is too great.
   - Break playbooks. Always keep backwards compatibility in mind.
   - Forget to keep it simple. Complexity breeds all kinds of problems.
@@ -55,12 +55,12 @@ Individuals with direct commit access to ansible/ansible are entrusted with powe
 
   - Squash, avoid merges whenever possible, use github's squash commits or cherry pick if needed (bisect thanks you).
   - Be active. Committers who have no activity on the project (through merges, triage, commits, etc.) will have their permissions suspended.
-  - Consider backwards compatibility (goes back to "don’t break existing playbooks").
+  - Consider backwards compatibility (goes back to "don't break existing playbooks").
   - Write tests. PRs with tests are looked at with more priority than PRs without tests that should have them included. While not all changes require tests, be sure to add them for bug fixes or functionality changes.
   - Discuss with other committers, specially when you are unsure of something.
   - Document! If your PR is a new feature or a change to behavior, make sure you've updated all associated documentation or have notified the right people to do so. It also helps to add the version of Core against which this documentation is compatible (to avoid confusion with stable versus devel docs, for backwards compatibility, etc.).
   - Consider scope, sometimes a fix can be generalized
-  - Keep it simple, then things are maintainable, debuggable and intelligible.
+  - Keep it simple, then things are maintainable, debuggable, and intelligible.
 
 Committers are expected to continue to follow the same community and contribution guidelines followed by the rest of the Ansible community. 
 

docs/docsite/rst/community.rst

@@ -2,7 +2,7 @@ Community Information & Contributing
 ````````````````````````````````````
 
 Ansible is an open source project designed to bring together administrators and developers of all kinds to collaborate on building
-IT automation solutions that work well for them.   
+IT automation solutions that work well for them.
 
 Should you wish to get more involved -- whether in terms of just asking a question, helping other users, introducing new people to Ansible, or helping with the software or documentation, we welcome your contributions to the project.
 
@@ -16,7 +16,7 @@ I've Got A Question
 
 We're happy to help!
 
-Ansible questions are best asked on the `Ansible Google Group Mailing List <http://groups.google.com/group/ansible-project>`_.  
+Ansible questions are best asked on the `Ansible Google Group Mailing List <http://groups.google.com/group/ansible-project>`_.
 
 This is a very large high-traffic list for answering questions and sharing tips
 and tricks. Anyone can join, and email delivery is optional if you just want to read the group online.  To cut down on spam, your first post is moderated, though posts are approved quickly.
@@ -42,10 +42,10 @@ This is a low-traffic read-only list, where we'll share release announcements an
 I'd Like To Help Share and Promote Ansible
 ------------------------------------------
 
-You can help share Ansible with others by telling friends and colleagues, writing a blog post, 
-or presenting at user groups (like DevOps groups or the local LUG).  
+You can help share Ansible with others by telling friends and colleagues, writing a blog post,
+or presenting at user groups (like DevOps groups or the local LUG).
 
-You are also welcome to share slides on speakerdeck, sign up for a free account and tag it “Ansible”. On Twitter, 
+You are also welcome to share slides on speakerdeck, sign up for a free account, and tag it "Ansible". On Twitter,
 you can also share things with #ansible and may wish to `follow us <https://twitter.com/ansible>`_.
 
 I'd Like To Help Ansible Move Faster
@@ -73,31 +73,31 @@ more quickly.
 Do not use the issue tracker for "how do I do this" type questions.  These are great candidates
 for IRC or the mailing list instead where things are likely to be more of a discussion.
 
-To be respectful of reviewers' time and allow us to help everyone efficiently, please 
+To be respectful of reviewers' time and allow us to help everyone efficiently, please
 provide minimal well-reduced and well-commented examples versus sharing your entire production
-playbook.  Include playbook snippets and output where possible.  
+playbook.  Include playbook snippets and output where possible.
 
 When sharing YAML in playbooks, formatting can be preserved by using `code blocks <https://help.github.com/articles/creating-and-highlighting-code-blocks/>`_.
 
 For multiple-file content, we encourage use of gist.github.com.  Online pastebin content can expire, so it's nice to have things around for a longer term if they
 are referenced in a ticket.
 
-If you are not sure if something is a bug yet, you are welcome to ask about something on 
-the mailing list or IRC first.  
+If you are not sure if something is a bug yet, you are welcome to ask about something on
+the mailing list or IRC first.
 
-As we are a very high volume project, if you determine that 
+As we are a very high volume project, if you determine that
 you do have a bug, please be sure to open the issue yourself to ensure we have a record of
-it. Don’t rely on someone else in the community to file the bug report for you.
+it. Don't rely on someone else in the community to file the bug report for you.
 
 It may take some time to get to your report, see our information about priority flags below.
 
 I'd Like To Help With Documentation
 -----------------------------------
 
-Ansible documentation is a community project too!  
+Ansible documentation is a community project too!
 
-If you would like to help with the 
-documentation, whether correcting a typo or improving a section, or maybe even 
+If you would like to help with the
+documentation, whether correcting a typo or improving a section, or maybe even
 documenting a new feature, submit a GitHub pull request to  the code that
 lives in the ``docsite/rst`` subdirectory of the project for most pages, and there is an "Edit on GitHub"
 link up on those.
@@ -107,9 +107,9 @@ Module documentation is generated from a ``DOCUMENTATION`` structure embedded in
 For more information on module documentation see `How to document modules <http://docs.ansible.com/ansible/dev_guide/developing_modules_documenting.html>`_.
 
 Aside from modules, the main docs are in restructured text
-format.  
+format.
 
-If you aren’t comfortable with restructured text, you can also open a ticket on 
+If you aren't comfortable with restructured text, you can also open a ticket on
 GitHub about any errors you spot or sections you would like to see added. For more information
 on creating pull requests, please refer to the
 `GitHub help guide <https://help.github.com/articles/using-pull-requests>`_.
@@ -155,7 +155,7 @@ If you make a mistake you do not need to close your PR. Instead, create a clean
 with ``--force`` to overwrite the existing branch (permissible in this case as no one else should be using that
 branch as reference). Code comments won't be lost, they just won't be attached to the existing branch.
 
-We’ll then review your contributions and engage with you about questions and  so on.
+We'll then review your contributions and engage with you about questions and  so on.
 
 Because we have a very large and active community it may take awhile to get your contributions
 in!  See the notes about priorities in a later section for understanding our work queue.
@@ -171,18 +171,18 @@ Contributions can be for new features like modules, or to fix bugs you or others
 are interested in writing new modules to be included in the core Ansible distribution, please refer
 to the `module development documentation <http://docs.ansible.com/developing_modules.html>`_.
 
-Ansible's aesthetic encourages simple, readable code and consistent,
-conservatively extending, backwards-compatible improvements. When contributing code to Ansible, 
+Ansible's aesthetic encourages simple, readable code, and consistent,
+conservatively extending, backwards-compatible improvements. When contributing code to Ansible,
 please observe the following guidelines:
 
 - Code developed for Ansible needs to support Python2-2.6 or higher and Python3-3.5 or higher.
 - Use a 4-space indent, not  tabs.
 - We do not enforce 80 column lines; up to 160 columns are acceptable.
 - We do not accept 'style only' pull requests unless the code is nearly unreadable.
-- We are "PEP8ish", but not strictly compliant, see :doc:`testing_pep8` for more information.
+- We are not strictly compliant with PEP8. See :doc:`dev_guide/testing_pep8` for more information.
 
 You can also contribute by testing and revising other requests, especially if it is one you are interested
-in using. Please keep your comments clear and to the point, courteous and constructive, tickets are not a
+in using. Please keep your comments clear, to the point, courteous, and constructive, tickets are not a
 good place to start discussions (ansible-devel and IRC exist for this).
 
 Tip: To easily run from a checkout, source ``./hacking/env-setup`` and that's it -- no install
@@ -194,7 +194,7 @@ Other Topics
 Ansible Staff
 -------------
 
-Ansible, Inc is a company supporting Ansible and building additional solutions based on
+Ansible, Inc. is a company supporting Ansible and building additional solutions based on
 Ansible.  We also do services and support for those that are interested. We also offer an
 enterprise web front end to Ansible (see Tower below).
 
@@ -228,7 +228,7 @@ To subscribe to a group from a non-google account, you can send an email to the
 IRC Meetings
 ------------
 
-The Ansible community holds regular IRC meetings on various topics, and anyone who is interested is invited to 
+The Ansible community holds regular IRC meetings on various topics, and anyone who is interested is invited to
 participate. For more information about Ansible meetings, consult the `meeting schedule and agenda page <https://github.com/ansible/community/blob/master/meetings/README.md>`_.
 
 Release Numbering
@@ -286,7 +286,7 @@ These labels don't really have a definition - they are a simple ordering.  Howev
 affecting a major module (yum, apt, etc) is likely to be prioritized higher than a module
 affecting a smaller number of users.
 
-Since we place a strong emphasis on testing and code review, it may take a few months for a minor feature to get merged. This doesn't mean that we'll be exhausting all of the higher-priority queues before getting to your ticket; we will also take periodic sweeps through the lower priority queues and give them some attention as well, particularly in the area of new module changes. 
+Since we place a strong emphasis on testing and code review, it may take a few months for a minor feature to get merged. This doesn't mean that we'll be exhausting all of the higher-priority queues before getting to your ticket; we will also take periodic sweeps through the lower priority queues and give them some attention as well, particularly in the area of new module changes.
 
 
 Every bit of effort helps - if you're wishing to expedite the inclusion of a P3 feature pull request for instance, the best thing you can do is help close P2 bug reports.
@@ -310,7 +310,7 @@ All Ansible events and participants therein are governed by this Code of Conduct
 anti-harassment policy. We expect organizers to enforce these guidelines throughout all events,
 and we expect attendees, speakers, sponsors, and volunteers to help ensure a safe
 environment for our whole community. Specifically, this Code of Conduct covers
-participation in all Ansible-related forums and mailing lists, code and documentation
+participation in all Ansible-related forums, mailing lists, code, documentation
 contributions, public IRC channels, private correspondence, and public meetings.
 
 Ansible community members are...
@@ -341,7 +341,7 @@ rudeness, hostility, threatening behavior, abuse (verbal or physical), or person
 **Kind**
 
 Everyone should feel welcome in the Ansible community, regardless of their background.
-Please be courteous, respectful and polite to fellow community members. Do not make or
+Please be courteous, respectful, and polite to fellow community members. Do not make or
 post offensive comments related to skill level, gender, gender identity or expression,
 sexual orientation, disability, physical appearance, body size, race, or religion.
 Sexualized images or imagery, real or implied violence, intimidation, oppression,

docs/docsite/rst/community/development_process.rst

@@ -41,9 +41,9 @@ Each module has at least one assigned maintainer, listed in a `maintainer's file
 .. _Ansibullbot: https://github.com/ansible/ansibullbot/blob/master/ISSUE_HELP.md
 .. _maintainer's file: https://github.com/ansible/ansible/blob/devel/.github/BOTMETA.yml
 
-Some modules have no community maintainers assigned. In this case, the maintainer is listed as ``$team_ansible``. Ultimately, it’s our goal to have at least one community maintainer for every module.
+Some modules have no community maintainers assigned. In this case, the maintainer is listed as ``$team_ansible``. Ultimately, it's our goal to have at least one community maintainer for every module.
 
-The maintainer’s job is to review PRs and decide whether that PR should be merged (``shipit``) or revised (``needs_revision``).
+The maintainer's job is to review PRs and decide whether that PR should be merged (``shipit``) or revised (``needs_revision``).
 
 The ultimate goal of any pull request is to reach **shipit** status, where the Core team then decides whether the PR is ready to be merged. Not every PR that reaches the **shipit** label is actually ready to be merged, but the better our reviewers are, and the better our guidelines are, the more likely it will be that a PR that reaches **shipit** will be mergeable.
 
@@ -54,7 +54,7 @@ Workflow
 
 Ansibullbot runs continuously. You can generally expect to see changes to your issue or pull request within thirty minutes. Ansibullbot examines every open pull request in the repositories, and enforces state roughly according to the following workflow:
 
--  If a pull request has no workflow labels, it’s considered **new**. Files in the pull request are identified, and the maintainers of those files are pinged by the bot, along with instructions on how to review the pull request. (Note: sometimes we strip labels from a pull request to “reboot” this process.)
+-  If a pull request has no workflow labels, it's considered **new**. Files in the pull request are identified, and the maintainers of those files are pinged by the bot, along with instructions on how to review the pull request. (Note: sometimes we strip labels from a pull request to "reboot" this process.)
 -  If the module maintainer is not ``$team_ansible``, the pull request then goes into the **community_review** state.
 -  If the module maintainer is ``$team_ansible``, the pull request then goes into the **core_review** state (and probably sits for a while).
 -  If the pull request is in **community_review** and has received comments from the maintainer:
@@ -110,4 +110,4 @@ Special Labels
 
 -  **new_plugin**: this is for new modules or plugins that are not yet in Ansible.
 
-   **Note:** `new_plugin` kicks off a completely separate process, and frankly it doesn’t work very well at present. We’re working our best to improve this process.
+   **Note:** `new_plugin` kicks off a completely separate process, and frankly it doesn't work very well at present. We're working our best to improve this process.

docs/docsite/rst/community/maintainers.rst

@@ -15,13 +15,13 @@ In addition to the information below, module maintainers should be familiar with
 Maintainer Responsibilities
 ===========================
 
-When you contribute a new module to the [ansible/ansible](https://github.com/ansible/ansible) repository, you become the maintainer for that module once it has been merged. Maintainership empowers you with the authority to accept, reject, or request revisions to pull requests on your module -- but as they say, "with great power comes great responsibility."
+When you contribute a new module to the `ansible/ansible <https://github.com/ansible/ansible>`_ repository, you become the maintainer for that module once it has been merged. Maintainership empowers you with the authority to accept, reject, or request revisions to pull requests on your module -- but as they say, "with great power comes great responsibility."
 
 Maintainers of Ansible modules are expected to provide feedback, responses, or actions on pull requests or issues to the module(s) they maintain in a reasonably timely manner.
 
-It is also recommended that you occasionally revisit the [contribution guidelines](https://github.com/ansible/ansible/blob/devel/CONTRIBUTING.md), as they are continually refined. Occasionally, you may be requested to update your module to move it closer to the general accepted standard requirements. We hope for this to be infrequent, and will always be a request with a fair amount of lead time (ie: not by tomorrow!).
+It is also recommended that you occasionally revisit the `contribution guidelines <https://github.com/ansible/ansible/blob/devel/CONTRIBUTING.md>`_, as they are continually refined. Occasionally, you may be requested to update your module to move it closer to the general accepted standard requirements. We hope for this to be infrequent, and will always be a request with a fair amount of lead time (ie: not by tomorrow!).
 
-Finally, following the [ansible-devel](https://groups.google.com/forum/#!forum/ansible-devel) mailing list can be a great way to participate in the broader Ansible community, and a place where you can influence the overall direction, quality, and goals of Ansible and its modules. If you're not on this relatively low-volume list, please join us here: https://groups.google.com/forum/#!forum/ansible-devel
+Finally, following the `ansible-devel <https://groups.google.com/forum/#!forum/ansible-devel>`_ mailing list can be a great way to participate in the broader Ansible community, and a place where you can influence the overall direction, quality, and goals of Ansible and its modules. If you're not on this relatively low-volume list, please join us here: https://groups.google.com/forum/#!forum/ansible-devel
 
 The Ansible community hopes that you will find that maintaining your module is as rewarding for you as having the module is for the wider community.
 
@@ -31,21 +31,21 @@ Pull Requests, Issues, and Workflow
 Pull Requests
 -------------
 
-Module pull requests are located in the [main Ansible repository](https://github.com/ansible/ansible/pulls).
+Module pull requests are located in the `main Ansible repository <https://github.com/ansible/ansible/pulls>`_.
 
 Because of the high volume of pull requests, notification of PRs to specific modules are routed by an automated bot to the appropriate maintainer for handling. It is recommended that you set an appropriate notification process to receive notifications which mention your GitHub ID.
 
 Issues
 ------
 
-Issues for modules, including bug reports, documentation bug reports, and feature requests, are tracked in the [ansible repository](https://github.com/ansible/ansible/issues).
+Issues for modules, including bug reports, documentation bug reports, and feature requests, are tracked in the `ansible repository <https://github.com/ansible/ansible/issues>`_.
 
 Issues for modules are routed to their maintainers via an automated process. This process is still being refined, and currently depends upon the issue creator to provide adequate details (specifically, providing the proper module name) in order to route it correctly. If you are a maintainer of a specific module, it is recommended that you periodically search module issues for issues which mention your module's name (or some variation on that name), as well as setting an appropriate notification process for receiving notification of mentions of your GitHub ID.
 
 PR Workflow
 -----------
 
-Automated routing of pull requests is handled by a tool called [Ansibot](https://github.com/ansible/ansibullbot). 
+Automated routing of pull requests is handled by a tool called `Ansibot <https://github.com/ansible/ansibullbot>`_.
 
 Being moderately familiar with how the workflow behind the bot operates can be helpful to you, and -- should things go awry -- your feedback can be helpful to the folks that continually help Ansibullbot to evolve.
 

docs/docsite/rst/community/reporting_bugs_and_features.rst

@@ -25,7 +25,7 @@ For multiple-file content, we encourage use of gist.github.com.  Online pastebin
 
 If you are not sure if something is a bug yet, you are welcome to ask about something on the mailing list or IRC first.
 
-As we are a very high volume project, if you determine that you do have a bug, please be sure to open the issue yourself to ensure we have a record of it. Don’t rely on someone else in the community to file the bug report for you.
+As we are a very high volume project, if you determine that you do have a bug, please be sure to open the issue yourself to ensure we have a record of it. Don't rely on someone else in the community to file the bug report for you.
 
 Requesting a feature
 ====================

docs/docsite/rst/dev_guide/developing_api.rst

@@ -44,8 +44,8 @@ In 2.0 things get a bit more complicated to start, but you end up with much more
     import json
     from collections import namedtuple
     from ansible.parsing.dataloader import DataLoader
-    from ansible.vars import VariableManager
-    from ansible.inventory import Inventory
+    from ansible.vars.manager import VariableManager
+    from ansible.inventory.manager import InventoryManager
     from ansible.playbook.play import Play
     from ansible.executor.task_queue_manager import TaskQueueManager
     from ansible.plugins.callback import CallbackBase
@@ -63,21 +63,21 @@ In 2.0 things get a bit more complicated to start, but you end up with much more
             This method could store the result in an instance attribute for retrieval later
             """
             host = result._host
-            print json.dumps({host.name: result._result}, indent=4)
+            print(json.dumps({host.name: result._result}, indent=4))
 
-    Options = namedtuple('Options', ['connection', 'module_path', 'forks', 'become', 'become_method', 'become_user', 'check'])
+    Options = namedtuple('Options', ['connection', 'module_path', 'forks', 'become', 'become_method', 'become_user', 'check', 'diff'])
     # initialize needed objects
-    variable_manager = VariableManager()
     loader = DataLoader()
-    options = Options(connection='local', module_path='/path/to/mymodules', forks=100, become=None, become_method=None, become_user=None, check=False)
+    options = Options(connection='local', module_path='/path/to/mymodules', forks=100, become=None, become_method=None, become_user=None, check=False,
+                      diff=False)
     passwords = dict(vault_pass='secret')
 
     # Instantiate our ResultCallback for handling results as they come in
     results_callback = ResultCallback()
 
     # create inventory and pass to var manager
-    inventory = Inventory(loader=loader, variable_manager=variable_manager, host_list='localhost')
-    variable_manager.set_inventory(inventory)
+    inventory = InventoryManager(loader=loader, sources=['localhost'])
+    variable_manager = VariableManager(loader=loader, inventory=inventory)
 
     # create play with tasks
     play_source =  dict(

docs/docsite/rst/dev_guide/developing_modules_checklist.rst

@@ -55,7 +55,7 @@ The complete module metadata specification is here: `Ansible metadata block <htt
     * Examples--include them whenever possible and make sure they are reproducible.
     * Document the return structure of the module. Refer to :ref:`common_return_values` and :ref:`module_documenting` for additional information.
 * Predictable user interface: This is a particularly important section as it is also an area where we need significant improvements.
-    * Name consistency across modules (we’ve gotten better at this, but we still have many deviations).
+    * Name consistency across modules (we've gotten better at this, but we still have many deviations).
     * Declarative operation (not CRUD)--this makes it easy for a user not to care what the existing state is, just about the final state. ``started/stopped``, ``present/absent``--don't overload options too much. It is preferable to add a new, simple option than to add choices/states that don't fit with existing ones.
     * Keep options small, having them take large data structures might save us a few tasks, but adds a complex requirement that we cannot easily validate before passing on to the module.
     * Allow an "expert mode". This may sound like the absolute opposite of the previous one, but it is always best to let expert users deal with complex data. This requires different modules in some cases, so that you end up having one (1) expert module and several 'piecemeal' ones (ec2_vpc_net?). The reason for this is not, as many users express, because it allows a single task and keeps plays small (which just moves the data complexity into vars files, leaving you with a slightly different structure in another YAML file). It does, however, allow for a more 'atomic' operation against the underlying APIs and services.

docs/docsite/rst/dev_guide/developing_modules_documenting.rst

@@ -109,11 +109,11 @@ Structure
 Fields
 ^^^^^^
 
-:metadata_version: An “X.Y” formatted string. X and Y are integers which
+:metadata_version: An "X.Y" formatted string. X and Y are integers which
    define the metadata format version. Modules shipped with Ansible are
    tied to an Ansible release, so we will only ship with a single version
-   of the metadata. We’ll increment Y if we add fields or legal values
-   to an existing field. We’ll increment X if we remove fields or values
+   of the metadata. We'll increment Y if we add fields or legal values
+   to an existing field. We'll increment X if we remove fields or values
    or change the type or meaning of a field.
    Current metadata_version is "1.1"
 :supported_by: This field records who supports the module.
@@ -130,13 +130,13 @@ Fields
    `Modules Support <http://docs.ansible.com/ansible/modules_support.html>`_.
 
 :status: This field records information about the module that is
-   important to the end user. It’s a list of strings. The default value
-   is a single element list [“preview”]. The following strings are valid
+   important to the end user. It's a list of strings. The default value
+   is a single element list ["preview"]. The following strings are valid
    statuses and have the following meanings:
 
-   :stableinterface: This means that the module’s parameters are
+   :stableinterface: This means that the module's parameters are
       stable. Every effort will be made not to remove parameters or change
-      their meaning. It is not a rating of the module’s code quality.
+      their meaning. It is not a rating of the module's code quality.
    :preview: This module is a tech preview. This means it may be
       unstable, the parameters may change, or it may require libraries or
       web services that are themselves subject to incompatible changes.
@@ -223,6 +223,8 @@ The following fields can be used and are all required unless specified otherwise
     * If `required` is false/missing, `default` may be specified (assumed 'null' if missing).
     * Ensure that the default parameter in the docs matches the default parameter in the code.
     * The default option must not be listed as part of the description.
+    * If the option is a boolean value, you can use any of the boolean values recognized by Ansible:
+      (such as true/false or yes/no).  Choose the one that reads better in the context of the option.
   :choices:
     List of option values. Should be absent if empty.
   :type:

docs/docsite/rst/dev_guide/developing_modules_in_groups.rst

@@ -26,7 +26,7 @@ Although it's tempting to get straight into coding, there are a few things to be
 * Shared code can be placed into ``lib/ansible/module_utils/``
 * Shared documentation (for example describing common arguments) can be placed in ``lib/ansible/utils/module_docs_fragments/``.
 * With great power comes great responsibility: Ansible module maintainers have a duty to help keep modules up to date. As with all successful community projects, module maintainers should keep a watchful eye for reported issues and contributions.
-* Although not required, unit and/or integration tests are strongly recommended. Unit tests are especially valuable when external resources (such as cloud or network devices) are required. For more information see :doc:`testing` and the `Testing Working Group <https://github.com/ansible/community/blob/master/meetings/README.md>`_.
+* Although not required, unit and/or integration tests are strongly recommended. Unit tests are especially valuable when external resources (such as cloud or network devices) are required. For more information see :doc:`dev_guide/testing` and the `Testing Working Group <https://github.com/ansible/community/blob/master/meetings/README.md>`_.
   * Starting with Ansible 2.4 all :doc:`../list_of_network_modules` MUST have unit tests.
 
 

docs/docsite/rst/dev_guide/developing_python3.rst

@@ -295,7 +295,7 @@ new exception-catching syntax which uses the ``as`` keyword:
 Do **not** use the following syntax as it will fail on every version of Python-3:
 
 .. This code block won't highlight because python2 isn't recognized. This is necessary to pass tests under python 3.
-.. code-block:: python2
+.. code-block:: none
 
     try:
         a = 2/0

docs/docsite/rst/dev_guide/index.rst

@@ -30,7 +30,6 @@ To get started, select one of the following topics.
    developing_core
    developing_python3
    developing_api
-   developing_test_pr
    developing_rebasing
    testing
    repomerge

docs/docsite/rst/dev_guide/overview_architecture.rst

@@ -25,7 +25,7 @@ Inventory
 
 By default, Ansible represents what machines it manages using a very simple INI file that puts all of your managed machines in groups of your own choosing.
 
-To add new machines, there is no additional SSL signing server involved, so there's never any hassle deciding why a particular machine didn’t get linked up due to obscure NTP or DNS issues.
+To add new machines, there is no additional SSL signing server involved, so there's never any hassle deciding why a particular machine didn't get linked up due to obscure NTP or DNS issues.
 
 If there's another source of truth in your infrastructure, Ansible can also plugin to that, such as drawing inventory, group, and variable information from sources like EC2, Rackspace, OpenStack, and more.
 
@@ -69,4 +69,4 @@ Here's what a simple playbook looks like::
 Extending Ansible with Plug-ins and the API
 ````````````````````````````````````````````
 
-Should you want to write your own, Ansible modules can be written in any language that can return JSON (Ruby, Python, bash, etc). Inventory can also plug in to any datasource by writing a program that speaks to that datasource and returns JSON. There's also various Python APIs for extending Ansible’s connection types (SSH is not the only transport possible), callbacks (how Ansible logs, etc), and even for adding new server side behaviors.
+Should you want to write your own, Ansible modules can be written in any language that can return JSON (Ruby, Python, bash, etc). Inventory can also plug in to any datasource by writing a program that speaks to that datasource and returns JSON. There's also various Python APIs for extending Ansible's connection types (SSH is not the only transport possible), callbacks (how Ansible logs, etc), and even for adding new server side behaviors.

docs/docsite/rst/dev_guide/style_guide/grammar_punctuation.rst

@@ -110,7 +110,7 @@ Never use "we" when writing. "We" aren't doing anything on the user side. Ansibl
 
 Hyphen
 ~~~~~~~~~~~~~~
-The hyphen’s primary function is the formation of certain compound terms. Do not use a hyphen unless it serves a purpose. If a compound adjective cannot be misread or, as with many psychological terms, its meaning is established, a hyphen is not necessary.
+The hyphen's primary function is the formation of certain compound terms. Do not use a hyphen unless it serves a purpose. If a compound adjective cannot be misread or, as with many psychological terms, its meaning is established, a hyphen is not necessary.
 
 Use hyphens to avoid ambiguity or confusion:
 

docs/docsite/rst/dev_guide/style_guide/spelling_word_choice.rst

@@ -78,7 +78,7 @@ Use to describes where to place options for a command, but not where to type the
 Daylight saving time (DST)
 +++++++++++++++++++++++++++++++
 
-Correct. Do not use daylight savings time. Daylight Saving Time (DST) is often misspelled “Daylight Savings”, with an “s” at the end. Other common variations are “Summer Time”and “Daylight-Saving Time”. (http://www.timeanddate.com/time/dst/daylight-savings-time.html)
+Correct. Do not use daylight savings time. Daylight Saving Time (DST) is often misspelled "Daylight Savings", with an "s" at the end. Other common variations are "Summer Time"and "Daylight-Saving Time". (http://www.timeanddate.com/time/dst/daylight-savings-time.html)
 
 
 Download
@@ -99,7 +99,7 @@ When used as a verb, fail over is two words since there can be different tenses
 
 Fewer
 +++++++++++++++++++
-Fewer is used with plural nouns. Think things you could count.  Time, money, distance, and weight are often listed as exceptions to the traditional “can you count it” rule, often thought of a singular amounts (the work will take less than 5 hours, for example).
+Fewer is used with plural nouns. Think things you could count.  Time, money, distance, and weight are often listed as exceptions to the traditional "can you count it" rule, often thought of a singular amounts (the work will take less than 5 hours, for example).
 
 File name
 +++++++++++++

docs/docsite/rst/dev_guide/style_guide/why_use.rst

@@ -13,8 +13,8 @@ This style guide incorporates current Ansible resources and information so that
 
    <blockquote class="note info">
 
-   “If you don't find it in the index, look very carefully through the entire catalogue.” 
-    ― Sears, Roebuck and Co., 1897 Sears Roebuck & Co. Catalogue 
+   "If you don't find it in the index, look very carefully through the entire catalogue."
+    ― Sears, Roebuck and Co., 1897 Sears Roebuck & Co. Catalogue
  
 .. raw:: html
 

docs/docsite/rst/dev_guide/testing.rst

@@ -33,9 +33,14 @@ At a high level we have the following classifications of tests:
   * Tests directly against individual parts of the code base.
 
 
-If you're a developer, one of the most valuable things you can do is look at the GitHub issues list and help fix bugs.  We almost always prioritize bug fixing over feature development, so helping to fix bugs is one of the best things you can do.
+If you're a developer, one of the most valuable things you can do is look at the GitHub
+issues list and help fix bugs.  We almost always prioritize bug fixing over feature
+development.
 
-Even if you're not a developer, helping to test pull requests for bug fixes and features is still immensely valuable.
+Even for non developers, helping to test pull requests for bug fixes and features is still
+immensely valuable.  Ansible users who understand writing playbooks and roles should be
+able to add integration tests and so Github pull requests with integration tests that show
+bugs in action will also be a great way to help.
 
 
 Testing within GitHub & Shippable
@@ -47,7 +52,6 @@ Organization
 
 When Pull Requests (PRs) are created they are tested using Shippable, a Continuous Integration (CI) tool. Results are shown at the end of every PR.
 
-
 When Shippable detects an error and it can be linked back to a file that has been modified in the PR then the relevant lines will be added as a GitHub comment. For example::
 
    The test `ansible-test sanity --test pep8` failed with the following errors:
@@ -69,7 +73,6 @@ Then run the tests detailed in the GitHub comment::
   ansible-test sanity --test pep8
   ansible-test sanity --test validate-modules
 
-
 If there isn't a GitHub comment stating what's failed you can inspect the results by clicking on the "Details" button under the "checks have failed" message at the end of the PR.
 
 Rerunning a failing CI job
@@ -91,10 +94,6 @@ If the issue persists, please contact us in ``#ansible-devel`` on Freenode IRC.
 How to test a PR
 ================
 
-If you're a developer, one of the most valuable things you can do is look at the GitHub issues list and help fix bugs.  We almost always prioritize bug fixing over feature development, so helping to fix bugs is one of the best things you can do.
-
-Even if you're not a developer, helping to test pull requests for bug fixes and features is still immensely valuable.
-
 Ideally, code should add tests that prove that the code works. That's not always possible and tests are not always comprehensive, especially when a user doesn't have access to a wide variety of platforms, or is using an API or web service. In these cases, live testing against real equipment can be more valuable than automation that runs against simulated interfaces. In any case, things should always be tested manually the first time as well.
 
 Thankfully, helping to test Ansible is pretty straightforward, assuming you are familiar with how Ansible works.
@@ -188,8 +187,26 @@ If the PR does not resolve the issue, or if you see any failures from the unit/i
    |   some other output
    |   \```
 
+Code Coverage Online
+````````````````````
+
+`The online code coverage reports <https://codecov.io/gh/ansible/ansible>` are a good way
+to identify areas for testing improvement in Ansible.  By following red colors you can
+drill down through the reports to find files which have no tests at all.  Adding both
+integration and unit tests which show clearly how code should work, verify important
+Ansible functions and increase testing coverage in areas where there is none is a valuable
+way to help improve Ansible.
+
+The code coverage reports only cover the ``devel`` branch of Ansible where new feature
+development takes place.  Pull requests and new code will be missing from the codecov.io
+coverage reports so local reporting is needed.  Most ``ansible-test`` commands allow you
+to collect code coverage, this is particularly useful to indicate where to extend
+testing. See :doc:`testing_running_locally` for more information.
+
+
 Want to know more about testing?
 ================================
 
-If you'd like to know more about the plans for improving testing Ansible then why not join the `Testing Working Group <https://github.com/ansible/community/blob/master/meetings/README.md>`_.
+If you'd like to know more about the plans for improving testing Ansible then why not join the
+`Testing Working Group <https://github.com/ansible/community/blob/master/meetings/README.md>`_.
 

docs/docsite/rst/dev_guide/testing/sanity/azure-requirements.rst

@@ -0,0 +1,10 @@
+Sanity Tests » azure-requirements
+=================================
+
+Update the Azure integration test requirements file when changes are made to the Azure packaging requirements file:
+
+.. code-block:: bash
+
+    cp packaging/requirements/requirements-azure.txt test/runner/requirements/integration.cloud.azure.txt
+
+This copy of the requirements file is used when building the ``ansible/ansible:default`` Docker container from ``test/runner/Dockerfile``.

docs/docsite/rst/dev_guide/testing/sanity/no-smart-quotes.rst

@@ -0,0 +1,4 @@
+Sanity Tests » no-smart-quotes
+==============================
+
+Smart quotes (``”“‘’``) should not be used.  Use plain ascii quotes (``"'``) instead.

docs/docsite/rst/dev_guide/testing/sanity/no-unicode-literals.rst

@@ -0,0 +1,16 @@
+Sanity Tests » no-unicode_literals
+==================================
+
+The use of :code:`from __future__ import unicode_literals` has been deemed an anti-pattern.  The
+problems with it are:
+
+* It makes it so one can't jump into the middle of a file and know whether a bare literal string is
+  a byte string or text string.  The programmer has to first check the top of the file to see if the
+  import is there.
+* It removes the ability to define native strings (a string which should be a byte string on python2
+  and a text string on python3) via a string literal.
+* It makes for more context switching.  A programmer could be reading one file which has
+  `unicode_literals` and know that bare string literals are text strings but then switch to another
+  file (perhaps tracing program execution into a third party library) and have to switch their
+  understanding of what bare string literals are.
+

docs/docsite/rst/dev_guide/testing_running_locally.rst

@@ -45,7 +45,19 @@ Use the ``ansible-test shell`` command to get an interactive shell in the same e
 Code Coverage
 =============
 
-Add the ``--coverage`` option to any test command to collect code coverage data.
+Code coverage reports make it easy to identify untested code for which more tests should
+be written.  Online reports are available but only cover the ``devel`` branch (see
+:doc:`testing`).  For new code local reports are needed.
+
+Add the ``--coverage`` option to any test command to collect code coverage data.  If you
+aren't using the ``--tox`` or ``--docker`` options which create an isolated python
+environment then you may have to use the ``--requirements`` option to ensure that the
+correct version of the coverage module is installed
+
+   ansible-test units --coverage apt
+   ansible-test integration --coverage aws_lambda --tox --requirements
+   ansible-test coverage html
+
 
 Reports can be generated in several different formats:
 
@@ -53,4 +65,7 @@ Reports can be generated in several different formats:
 * ``ansible-test coverage html`` - HTML report.
 * ``ansible-test coverage xml`` - XML report.
 
-To clear data between test runs, use the ``ansible-test coverage erase`` command.
+To clear data between test runs, use the ``ansible-test coverage erase`` command. For a full list of features see the online help::
+
+   ansible-test coverage --help
+

docs/docsite/rst/dev_guide/testing_units.rst

@@ -2,19 +2,24 @@
 Unit Tests
 **********
 
-Unit tests are small isolated tests that target a specific library or module.
+Unit tests are small isolated tests that target a specific library or module.  Unit tests
+in Ansible are currently the only way of driving tests from python within Ansible's
+continuous integration process. This means that in some circumstances the tests may be a
+bit wider than just units.
 
 .. contents:: Topics
 
 Available Tests
 ===============
 
-Unit tests can be found in `test/units <https://github.com/ansible/ansible/tree/devel/test/units>`_, notice that the directory structure matches that of ``lib/ansible/``
+Unit tests can be found in `test/units
+<https://github.com/ansible/ansible/tree/devel/test/units>`_. Notice that the directory
+structure of the tests matches that of ``lib/ansible/``.
 
 Running Tests
 =============
 
-Unit tests can be run across the whole code base by doing:
+The Ansible unit tests can be run across the whole code base by doing:
 
 .. code:: shell
 
@@ -35,18 +40,22 @@ Or against a specific Python version by doing:
    ansible-test units --tox --python 2.7 apt
 
 
-
 For advanced usage see the online help::
 
    ansible-test units --help
 
+You can also run tests in Ansible's continuous integration system by opening a pull
+request.  This will automatically determine which tests to run based on the changes made
+in your pull request.
+
 
 Installing dependencies
 =======================
 
-``ansible-test`` has a number of dependencies , for ``units`` tests we suggest using ``tox``
+``ansible-test`` has a number of dependencies. For ``units`` tests we suggest using ``tox``.
 
-The dependencies can be installed using the ``--requirements`` argument, which will install all the required dependencies needed for unit tests. For example:
+The dependencies can be installed using the ``--requirements`` argument, which will
+install all the required dependencies needed for unit tests. For example:
 
 .. code:: shell
 
@@ -58,7 +67,11 @@ The dependencies can be installed using the ``--requirements`` argument, which w
    When using ``ansible-test`` with ``--tox`` requires tox >= 2.5.0
 
 
-The full list of requirements can be found at `test/runner/requirements <https://github.com/ansible/ansible/tree/devel/test/runner/requirements>`_. Requirements files are named after their respective commands. See also the `constraints <https://github.com/ansible/ansible/blob/devel/test/runner/requirements/constraints.txt>`_ applicable to all commands.
+The full list of requirements can be found at `test/runner/requirements
+<https://github.com/ansible/ansible/tree/devel/test/runner/requirements>`_. Requirements
+files are named after their respective commands. See also the `constraints
+<https://github.com/ansible/ansible/blob/devel/test/runner/requirements/constraints.txt>`_
+applicable to all commands.
 
 
 Extending unit tests
@@ -67,22 +80,98 @@ Extending unit tests
 
 .. warning:: What a unit test isn't
 
-   If you start writing a test that requires external services then you may be writing an integration test, rather than a unit test.
+   If you start writing a test that requires external services then
+   you may be writing an integration test, rather than a unit test.
+
+
+Structuring Unit Tests
+``````````````````````
+
+Ansible drives unit tests through `pytest <https://docs.pytest.org/en/latest/>`_. This
+means that tests can either be written a simple functions which are included in any file
+name like ``test_<something>.py`` or as classes. 
+
+Here is an example of a function::
+
+  #this function will be called simply because it is called test_*()
+
+  def test_add()
+      a = 10
+      b = 23
+      c = 33
+      assert a + b = c
+    
+Here is an example of a class::
+
+  import unittest:
+      
+  class AddTester(unittest.TestCase)
+      
+      def SetUp()
+          self.a = 10
+          self.b = 23
+ 
+      # this function will 
+      def test_add()
+        c = 33
+        assert self.a + self.b = c
+
+     # this function will 
+      def test_subtract()
+        c = -13
+        assert self.a - self.b = c
+
+Both methods work fine in most circumstances; the function-based interface is simpler and
+quicker and so that's probably where you should start when you are just trying to add a
+few basic tests for a module.  The class-based test allows more tidy set up and tear down
+of pre-requisites, so if you have many test cases for your module you may want to refactor
+to use that.  
+
+Assertions using the simple ``assert`` function inside the tests will give give full
+information on the cause of the failure with a trace-back of functions called during the
+assertion.  This means that plain asserts are recommended over other external assertion
+libraries.
+
+A number of the unit test suites include functions that are shared between several
+modules, especially in the networking arena.  In these cases a file is created in the same
+directory, which is then included directly.
+
+
+Module test case common code
+````````````````````````````
+
+Keep common code as specific as possible within the `test/units/` directory structure. For
+example, if it's specific to testing Amazon modules, it should be in
+`test/units/modules/cloud/amazon/`. Don't import common unit test code from directories
+outside the current or parent directories.
+
+Don't import other unit tests from a unit test. Any common code should be in dedicated
+files that aren't themselves tests.
+
 
 Fixtures files
 ``````````````
 
-To mock out fetching results from devices, you can use ``fixtures`` to read in pre-generated data.
+To mock out fetching results from devices, or provide other complex datastructures that
+come from external libraries, you can use ``fixtures`` to read in pre-generated data.
 
 Text files live in ``test/units/modules/network/PLATFORM/fixtures/``
 
 Data is loaded using the ``load_fixture`` method
 
-See  `eos_banner test <https://github.com/ansible/ansible/blob/devel/test/units/modules/network/eos/test_eos_banner.py>`_ for a practical example.
+See `eos_banner test
+<https://github.com/ansible/ansible/blob/devel/test/units/modules/network/eos/test_eos_banner.py>`_
+for a practical example.
 
-Code Coverage
-`````````````
-Most ``ansible-test`` commands allow you to collect code coverage, this is particularly useful when to indicate where to extend testing.
+If you are simulating APIs you may find that python placebo is useful.  See
+doc:`testing_units_modules` for more information.
+
+
+Code Coverage For New or Updated Unit Tests
+```````````````````````````````````````````
+New code will be missing from the codecov.io coverage reports (see :doc:`testing`), so
+local reporting is needed.  Most ``ansible-test`` commands allow you to collect code
+coverage; this is particularly useful when to indicate where to extend testing.
 
 To collect coverage data add the ``--coverage`` argument to your ``ansible-test`` command line:
 
@@ -99,7 +188,21 @@ Reports can be generated in several different formats:
 * ``ansible-test coverage html`` - HTML report.
 * ``ansible-test coverage xml`` - XML report.
 
-To clear data between test runs, use the ``ansible-test coverage erase`` command. For a full list of features see the online help::
+To clear data between test runs, use the ``ansible-test coverage erase`` command.  See
+:doc:`testing_units_running_locally` for more information about generating coverage
+reports.
 
-   ansible-test coverage --help
+
+.. seealso::
+
+   :doc:`testing_units_modules`
+       Special considerations for unit testing modules
+   :doc:`testing_running_locally`
+       Running tests locally including gathering and reporting coverage data
+   `Python 3 documentation - 26.4. unittest — Unit testing framework <https://docs.python.org/3/library/unittest.html>`_
+       The documentation of the unittest framework in python 3 
+   `Python 2 documentation - 25.3. unittest — Unit testing framework <https://docs.python.org/3/library/unittest.html>`_
+       The documentation of the earliest supported unittest framework - from Python 2.6
+   `pytest: helps you write better programs <https://docs.pytest.org/en/latest/>`_
+       The documentation of pytest - the framework actually used to run Ansible unit tests
 

docs/docsite/rst/dev_guide/testing_units_modules.rst

@@ -0,0 +1,555 @@
+****************************
+Unit Testing Ansible Modules
+****************************
+
+.. contents:: Topics
+
+Introduction
+============
+
+This document explains why, how and when you should use unit tests for Ansible modules.
+The document doesn't apply to other parts of Ansible for which the recommendations are
+normally closer to the Python standard.  There is basic documentation for Ansible unit
+tests in the developer guide :doc:`testing_units`.  This document should
+be readable for a new Ansible module author. If you find it incomplete or confusing, 
+please open a bug or ask for help on Ansible IRC.
+
+What Are Unit Tests?
+====================
+
+Ansible includes a set of unit tests in the :file:`test/unit` directory. These tests primarily cover the
+internals but can also can cover Ansible modules.  The structure of the unit tests matches
+the structure of the code base, so the tests that reside in the :file:`test/unit/modules/` directory
+are organized by module groups.
+
+Integration tests can be used for most modules, but there are situations where
+cases cannot be verified using integration tests.  This means that Ansible unit test cases
+may extend beyond testing only minimal units and in some cases will include some
+level of functional testing.
+
+
+Why Use Unit Tests?
+===================
+
+Ansible unit tests have advantages and disadvantages. It is important to understand these.
+Advantages include:
+
+* Most unit tests are much faster than most Ansible integration tests.  The complete suite
+  of unit tests can be run regularly by a developer on their local system.
+* Unit tests can be run by developers who don't have access to the system which the module is
+  designed to work on, allowing a level of verification that changes to core functions
+  haven't broken module expectations.
+* Unit tests can easily substitute system functions allowing testing of software that
+  would be impractical.  For example, the ``sleep()`` function can be replaced and we check
+  that a ten minute sleep was called without actually waiting ten minutes.
+* Unit tests are run on different Python versions. This allows us to
+  ensure that the code behaves in the same way on different Python versions.
+
+There are also some potential disadvantages of unit tests. Unit tests don't normally
+directly test actual useful valuable features of software, instead just internal
+implementation
+
+* Unit tests that test the internal, non-visible features of software may make
+  refactoring difficult if those internal features have to change (see also naming in How
+  below)
+* Even if the internal feature is working correctly it is possible that there will be a
+  problem between the internal code tested and the actual result delivered to the user
+
+Normally the Ansible integration tests (which are written in Ansible YAML) provide better
+testing for most module functionality.  If those tests already test a feature and perform
+well there may be little point in providing a unit test covering the same area as well.
+
+When To Use Unit Tests
+======================
+
+There are a number of situations where unit tests are a better choice than integration
+tests. For example, testing things which are impossible, slow or very difficult to test
+with integration tests, such as:
+    
+* Forcing rare / strange / random situations that can't be forced, such as specific network
+  failures and exceptions
+* Extensive testing of slow configuration APIs 
+* Situations where the integration tests cannot be run as part of the main Ansible
+  continuous integraiton running in Shippable.
+
+
+
+Providing quick feedback
+------------------------
+
+Example:
+  A single step of the rds_instance test cases can take up to 20
+  minutes (the time to create an RDS instance in Amazon).  The entire
+  test run can last for well over an hour.  All 16 of the unit tests
+  complete execution in less than 2 seconds.
+
+The time saving provided by being able to run the code in a unit test makes it worth
+creating a unit test when bug fixing a module, even if those tests do not often identify
+problems later.  As a basic goal, every module should have at least one unit test which
+will give quick feedback in easy cases without having to wait for the integration tests to
+complete.
+    
+Ensuring correct use of external interfaces
+-------------------------------------------
+
+Unit tests can check the way in which external services are run to ensure that they match 
+specifications or are as efficient as possible *even when the final output will not be changed*.
+
+Example:
+  Package managers are often far more efficient when installing multiple packages at once
+  rather than each package separately. The final result is the
+  same: the packages are all installed, so the efficiency is difficult to verify through
+  integration tests. By providing a mock package manager and verifying that it is called
+  once, we can build a valuable test for module efficiency.
+
+Another related use is in the situation where an API has versions which behave
+differently. A programmer working on a new version may change the module to work with the
+new API version and unintentially break the old version.  A test case
+which checks that the call happens properly for the old version can help avoid the
+problem.  In this situation it is very important to include version numbering in the test case
+name (see `Naming unit tests`_ below).
+
+Providing specific design tests 
+--------------------------------
+
+By building a requirement for a particular part of the
+code and then coding to that requirement, unit tests _can_ sometimes improve the code and
+help future developers understand that code. 
+
+Unit tests that test internal implementation details of code, on the other hand, almost
+always do more harm than good.  Testing that your packages to install are stored in a list
+would slow down and confuse a future developer who might need to change that list into a
+dictionary for efficiency. This problem can be reduced somewhat with clear test naming so
+that the future developer immediately knows to delete the test case, but it is often
+better to simply leave out the test case altogether and test for a real valuable feature
+of the code, such as installing all of the packages supplied as arguments to the module. 
+
+
+How to unit test Ansible modules
+================================
+
+There are a number of techniques for unit testing modules.  Beware that most
+modules without unit tests are structured in a way that makes testing quite difficult and
+can lead to very complicated tests which need more work than the code.  Effectively using unit
+tests may lead you to restructure your code. This is often a good thing and leads
+to better code overall. Good restructuring can make your code clearer and easier to understand.
+
+
+Naming unit tests
+-----------------
+
+Unit tests should have logical names. If a developer working on the module being tested
+breaks the test case, it should be easy to figure what the unit test covers from the name.
+If a unit test is designed to verify compatibility with a specific software or API version
+then include the version in the name of the unit test.
+
+As an example, ``test_v2_state_present_should_call_create_server_with_name()`` would be a
+good name, ``test_create_server()`` would not be.  
+
+
+Use of Mocks
+------------
+
+Mock objects (from https://docs.python.org/3/library/unittest.mock.html) can be very
+useful in building unit tests for special / difficult cases, but they can also
+lead to complex and confusing coding situations.  One good use for mocks would be in
+simulating an API. As for 'six', the 'mock' python package is bundled with Ansible (use
+'import ansible.compat.tests.mock'). See for example
+
+Ensuring failure cases are visible with mock objects
+----------------------------------------------------
+
+Functions like module.fail_json() are normally expected to terminate execution. When you 
+run with a mock module object this doesn't happen since the mock always returns another mock 
+from a function call. You can set up the mock to raise an exception as shown above, or you can
+assert that these functions have not been called in each test. For example::
+
+  module = MagicMock()
+  function_to_test(module, argument)
+  module.fail_json.assert_not_called() 
+
+This applies not only to calling the main module but almost any other
+function in a module which gets the module object.  
+
+
+Mocking of the actual module
+----------------------------
+
+The setup of an actual module is quite complex (see `Passing Arguments`_ below) and often
+isn't needed for most functions which use a module. Instead you can use a mock object as
+the module and create any module attributes needed by the function you are testing. If
+you do this, beware that the module exit functions need special handling as mentioned
+above, either by throwing an exception or ensuring that they haven't been called. For example::
+
+    class AnsibleExitJson(Exception):
+        """Exception class to be raised by module.exit_json and caught by the test case"""
+        pass
+    #you may also do the same to fail json
+    module=MagicMock()
+    module.exit_json.side_effect = AnsibleExitJson(Exception)
+    with self.assertRaises(AnsibleExitJson) as result:
+        return = my_module.test_this_function(module, argument)
+    module.fail_json.assert_not_called() 
+    assert return["changed"] == True
+    
+API definition with unit test cases
+-----------------------------------
+
+API interaction is usually best tested with the function tests defined in Ansible's
+integration testing section, which run against the actual API.  There are several cases
+where the unit tests are likely to work better.
+
+Defining a module against an API specification
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+This case is especially important for modules interacting with web services, which provide
+an API that Ansible uses but which are beyond the control of the user.
+
+By writing a custom emulation of the calls that return data from the API, we can ensure
+that only the features which are clearly defined in the specification of the API are
+present in the message.  This means that we can check that we use the correct
+parameters and nothing else.
+
+
+*Example:  in rds_instance unit tests a simple instance state is defined*::
+
+    def simple_instance_list(status, pending):
+        return {u'DBInstances': [{u'DBInstanceArn': 'arn:aws:rds:us-east-1:1234567890:db:fakedb',
+                                  u'DBInstanceStatus': status,
+                                  u'PendingModifiedValues': pending,
+                                  u'DBInstanceIdentifier': 'fakedb'}]}
+
+This is then used to create a list of states::
+
+    rds_client_double = MagicMock()
+    rds_client_double.describe_db_instances.side_effect = [
+        simple_instance_list('rebooting', {"a": "b", "c": "d"}),
+        simple_instance_list('available', {"c": "d", "e": "f"}),
+        simple_instance_list('rebooting', {"a": "b"}),
+        simple_instance_list('rebooting', {"e": "f", "g": "h"}),
+        simple_instance_list('rebooting', {}),
+        simple_instance_list('available', {"g": "h", "i": "j"}),
+        simple_instance_list('rebooting', {"i": "j", "k": "l"}),
+        simple_instance_list('available', {}),
+        simple_instance_list('available', {}),
+    ]
+    
+These states are then used as returns from a mock object to ensure that the ``await`` function
+waits through all of the states that would mean the RDS instance has not yet completed
+configuration::
+
+   rds_i.await_resource(rds_client_double, "some-instance", "available", mod_mock,
+                        await_pending=1)
+   assert(len(sleeper_double.mock_calls) > 5), "await_pending didn't wait enough"
+
+By doing this we check that the ``await`` function will keep waiting through
+potentially unusual that it would be impossible to reliably trigger through the
+integration tests but which happen unpredictably in reality.
+
+Defining a module to work against multiple API versions
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+This case is especially important for modules interacting with many different versions of
+software; for example, package installation modules that might be expected to work with
+many different operating system versions.
+
+By using previously stored data from various versions of an API we can ensure that the
+code is tested against the actual data which will be sent from that version of the system
+even when the version is very obscure and unlikely to be available during testing.
+
+Ansible special cases for unit testing
+======================================
+
+There are a number of special cases for unit testing the environment of an Ansible module.
+The most common are documented below, and suggestions for others can be found by looking
+at the source code of the existing unit tests or asking on the Ansible IRC channel or mailing
+lists.
+
+Module argument processing 
+--------------------------
+
+There are two problems with running the main function of a module:  
+
+* Since the module is supposed to accept arguments on ``STDIN`` it is a bit difficult to
+  set up the arguments correctly so that the module will get them as parameters.
+* All modules should finish by calling either the ``module.fail_json`` or
+  ``module.exit_json``, but these won't work correctly in a testing environment.
+
+Passing Arguments
+-----------------
+
+.. This section should be updated once https://github.com/ansible/ansible/pull/31456 is
+   closed since the function below will be provided in a library file.
+
+To pass arguments to a module correctly, use a function that stores the
+parameters in a special string variable.  Module creation and argument processing is
+handled through the AnsibleModule object in the basic section of the utilities. Normally
+this accepts input on ``STDIN``, which is not convenient for unit testing. When the special
+variable is set it will be treated as if the input came on ``STDIN`` to the module.::
+
+    import json
+    from ansible.module_utils._text import to_bytes
+
+    def set_module_args(args):
+        args = json.dumps({'ANSIBLE_MODULE_ARGS': args})
+        basic._ANSIBLE_ARGS = to_bytes(args)
+
+    simply call that function before setting up your module
+
+        def test_already_registered(self):
+            set_module_args({
+                'activationkey': 'key',
+                'username': 'user',
+                'password': 'pass',
+            })
+
+Handling exit correctly
+-----------------------
+
+.. This section should be updated once https://github.com/ansible/ansible/pull/31456 is
+   closed since the exit and failure functions below will be provided in a library file.
+
+The ``module.exit_json()`` function won't work properly in a testing environment since it
+writes error information to ``STDOUT`` upon exit, where it
+is difficult to examine. This can be mitigated by replacing it (and module.fail_json) with
+a function that raises an exception::
+
+    def exit_json(*args, **kwargs):
+        if 'changed' not in kwargs:
+            kwargs['changed'] = False
+        raise AnsibleExitJson(kwargs)
+
+Now you can ensure that the first function called is the one you expected simply by
+testing for the correct exception::
+
+    def test_returned_value(self):
+        set_module_args({
+            'activationkey': 'key',
+            'username': 'user',
+            'password': 'pass',
+        })
+       with self.assertRaises(AnsibleExitJson) as result:
+           my_module.main()
+
+The same technique can be used to replace ``module.fail_json()`` (which is used for failure
+returns from modules) and for the ``aws_module.fail_json_aws()`` (used in modules for Amazon
+Web Services).
+
+Running the main function
+-------------------------
+
+If you do want to run the actual main function of a module you must import the module, set
+the arguments as above, set up the appropriate exit exception and then run the module::
+
+    # This test is based around pytest's features for individual test functions
+    import pytest
+    import ansible.modules.module.group.my_modulle as my_module
+
+    def test_main_function(monkeypatch):
+        monkeypatch.setattr(my_module.AnsibleModule, "exit_json", fake_exit_json)
+        set_module_args({
+            'activationkey': 'key',
+            'username': 'user',
+            'password': 'pass',
+        })
+        my_module.main()
+
+
+Handling calls to external executables
+--------------------------------------
+
+Module must use AnsibleModule.run_command in order to execute an external command. This
+method needs to be mocked:
+
+Here is a simple mock of AnsibleModule.run_command (taken from test/units/modules/packaging/os/test_rhn_register.py and
+test/units/modules/packaging/os/rhn_utils.py)::
+
+        with patch.object(basic.AnsibleModule, 'run_command') as run_command:
+            run_command.return_value = 0, '', ''  # successful execution, no output
+                with self.assertRaises(AnsibleExitJson) as result:
+                    self.module.main()
+                self.assertFalse(result.exception.args[0]['changed'])
+        # Check that run_command has been called
+        run_command.assert_called_once_with('/usr/bin/command args')
+        self.assertEqual(run_command.call_count, 1)
+        self.assertFalse(run_command.called)
+
+
+A Complete Example
+------------------
+
+The following example is a complete skeleton that reuses the mocks explained above and adds a new
+mock for Ansible.get_bin_path::
+    
+    import json
+
+    from ansible.compat.tests import unittest
+    from ansible.compat.tests.mock import patch
+    from ansible.module_utils import basic
+    from ansible.module_utils._text import to_bytes
+    from ansible.modules.namespace import my_module
+
+
+    def set_module_args(args):
+        """prepare arguments so that they will be picked up during module creation"""
+        args = json.dumps({'ANSIBLE_MODULE_ARGS': args})
+        basic._ANSIBLE_ARGS = to_bytes(args)
+
+
+    class AnsibleExitJson(Exception):
+        """Exception class to be raised by module.exit_json and caught by the test case"""
+        pass
+
+
+    class AnsibleFailJson(Exception):
+        """Exception class to be raised by module.fail_json and caught by the test case"""
+        pass
+
+
+    def exit_json(*args, **kwargs):
+        """function to patch over exit_json; package return data into an exception"""
+        if 'changed' not in kwargs:
+            kwargs['changed'] = False
+        raise AnsibleExitJson(kwargs)
+
+
+    def fail_json(*args, **kwargs):
+        """function to patch over fail_json; package return data into an exception"""
+        kwargs['failed'] = True
+        raise AnsibleFailJson(kwargs)
+
+
+    def get_bin_path(self, arg, required=False):
+        """Mock AnsibleModule.get_bin_path"""
+        if arg.endswith('my_command'):
+            return '/usr/bin/my_command'
+        else:
+            if required:
+                fail_json(msg='%r not found !' % arg)
+
+
+    class TestMyModule(unittest.TestCase):
+
+        def setUp(self):
+            self.mock_module_helper = patch.multiple(basic.AnsibleModule,
+                                                     exit_json=exit_json,
+                                                     fail_json=fail_json,
+                                                     get_bin_path=get_bin_path)
+            self.mock_module_helper.start()
+            self.addCleanup(self.mock_module_helper.stop)
+
+        def test_module_fail_when_required_args_missing(self):
+            with self.assertRaises(AnsibleFailJson):
+                set_module_args({})
+                self.module.main()
+
+
+        def test_ensure_command_called(self):
+            set_module_args({
+                'param1': 10,
+                'param2': 'test',
+            })
+
+            with patch.object(basic.AnsibleModule, 'run_command') as mock_run_command:
+                stdout = 'configuration updated'
+                stderr = ''
+                rc = 0
+                mock_run_command.return_value = rc, stdout, stderr  # successful execution
+
+                with self.assertRaises(AnsibleExitJson) as result:
+                    my_module.main()
+                self.assertFalse(result.exception.args[0]['changed']) # ensure result is changed
+
+            mock_run_command.assert_called_once_with('/usr/bin/my_command --value 10 --name test')
+
+
+Restructuring modules to enable testing module set up and other processes
+-------------------------------------------------------------------------
+
+Often modules have a main() function which sets up the module and then performs other
+actions. This can make it difficult to check argument processing. This can be made easier by
+moving module configuration and initialization into a separate function. For example::
+
+    argument_spec = dict(
+        # module function variables
+        state=dict(choices=['absent', 'present', 'rebooted', 'restarted'], default='present'),
+        apply_immediately=dict(type='bool', default=False),
+        wait=dict(type='bool', default=False),
+        wait_timeout=dict(type='int', default=600),
+        allocated_storage=dict(type='int', aliases=['size']),
+        db_instance_identifier=dict(aliases=["id"], required=True),
+    )
+
+    def setup_module_object():
+        module = AnsibleAWSModule(
+            argument_spec=argument_spec,
+            required_if=required_if,
+            mutually_exclusive=[['old_instance_id', 'source_db_instance_identifier',
+                                 'db_snapshot_identifier']],
+        )
+        return module
+
+    def main():
+        module = setup_module_object()
+        validate_parameters(module)
+        conn = setup_client(module)
+        return_dict = run_task(module, conn)
+        module.exit_json(**return_dict)
+
+This now makes it possible to run tests against the module initiation function::
+
+    def test_rds_module_setup_fails_if_db_instance_identifier_parameter_missing():
+        # db_instance_identifier parameter is missing
+        set_module_args({
+            'state': 'absent',
+            'apply_immediately': 'True',
+         })
+
+        with self.assertRaises(AnsibleFailJson) as result:
+             self.module.setup_json
+
+See also ``test/units/module_utils/aws/test_rds.py``
+
+Note that the argument_spec dictionary is visible in a module variable. This has
+advantages, both in allowing explicit testing of the arguments and in allowing the easy
+creation of module objects for testing.
+
+The same restructuring technique can be valuable for testing other functionality, such as the part of the module which queries the object that the module configures.
+
+Traps for maintaining Python 2 compatibility
+============================================
+
+If you use the ``mock`` library from the Python 2.6 standard library, a number of the
+assert functions are missing but will return as if successful.  This means that test cases should take great care *not* use
+functions marked as _new_ in the Python 3 documentation, since the tests will likely always
+succeed even if the code is broken when run on older versions of Python.
+
+A helpful development approach to this should be to ensure that all of the tests have been
+run under Python 2.6 and that each assertion in the test cases has been checked to work by breaking
+the code in Ansible to trigger that failure.
+
+.. seealso::
+
+   :doc:`testing_units`
+       Ansible unit tests documentation
+   :doc:`testing_running_locally`
+       Running tests locally including gathering and reporting coverage data
+   :doc:`developing_modules`
+       How to develop modules
+   `Python 3 documentation - 26.4. unittest — Unit testing framework <https://docs.python.org/3/library/unittest.html>`_
+       The documentation of the unittest framework in python 3 
+   `Python 2 documentation - 25.3. unittest — Unit testing framework <https://docs.python.org/3/library/unittest.html>`_
+       The documentation of the earliest supported unittest framework - from Python 2.6
+   `pytest: helps you write better programs <https://docs.pytest.org/en/latest/>`_
+       The documentation of pytest - the framework actually used to run Ansible unit tests
+   `Development Mailing List <http://groups.google.com/group/ansible-devel>`_
+       Mailing list for development topics
+   `Testing Your Code (from The Hitchhiker's Guide to Python!) <http://docs.python-guide.org/en/latest/writing/tests/>`_
+       General advice on testing Python code
+   `Uncle Bob's many videos on YouTube <https://www.youtube.com/watch?v=QedpQjxBPMA&list=PLlu0CT-JnSasQzGrGzddSczJQQU7295D2>`_
+       Unit testing is a part of the of various philosophies of software development, including
+       Extreme Programming (XP), Clean Coding.  Uncle Bob talks through how to benfit from this
+   `"Why Most Unit Testing is Waste" http://rbcs-us.com/documents/Why-Most-Unit-Testing-is-Waste.pdf`
+       An article warning against the costs of unit testing
+   `'A Response to "Why Most Unit Testing is Waste"' https://henrikwarne.com/2014/09/04/a-response-to-why-most-unit-testing-is-waste/` 
+       An response pointing to how to maintain the value of unit tests

docs/docsite/rst/faq.rst

@@ -362,7 +362,7 @@ When should I use {{ }}? Also, how to interpolate variables or dynamic variable
 
 A steadfast rule is 'always use {{ }} except when `when:`'.
 Conditionals are always run through Jinja2 as to resolve the expression,
-so `when:`, `failed_when:` and `changed_when:` are always templated and you should avoid adding `{{}}`.
+so `when:`, `failed_when:`, and `changed_when:` are always templated and you should avoid adding `{{}}`.
 
 In most other cases you should always use the brackets, even if previously you could use variables without specifying (like `with_` clauses),
 as this made it hard to distinguish between an undefined variable and a string.

docs/docsite/rst/galaxy.rst

@@ -152,7 +152,7 @@ Content of the *requirements.yml* file:
     # from galaxy
     - src: yatesr.timezone
 
-    - include: <path_to_requirements>/webserver.yml
+    - import_tasks: <path_to_requirements>/webserver.yml
 
 
 Content of the *webserver.yml* file:
@@ -274,7 +274,7 @@ Alternatively, the role_skeleton and ignoring of files can be configured via ans
 Search for Roles
 ----------------
 
-Search the Galaxy database by tags, platforms, author and multiple keywords. For example:
+Search the Galaxy database by tags, platforms, author, and multiple keywords. For example:
 
 ::
 
@@ -361,7 +361,7 @@ Use ``remove`` to delete a role from *roles_path*:
 Authenticate with Galaxy
 ------------------------
 
-Using the ``import``, ``delete`` and ``setup`` commands to manage your roles on the Galaxy website requires authentication, and the ``login`` command
+Using the ``import``, ``delete``, and ``setup`` commands to manage your roles on the Galaxy website requires authentication, and the ``login`` command
 can be used to do just that. Before you can use the ``login`` command, you must create an account on the Galaxy website.
 
 The ``login`` command requires using your GitHub credentials. You can use your username and password, or you can create a `personal access token <https://help.github.com/articles/creating-an-access-token-for-command-line-use/>`_. If you choose to create a token, grant minimal access to the token, as it is used just to verify identify.
@@ -382,8 +382,8 @@ The following shows authenticating with the Galaxy website using a GitHub userna
     Password for dsmith:
     Successfully logged into Galaxy as dsmith
 
-When you choose to use your username and password, your password is not sent to Galaxy. It is used to authenticates with GitHub and create a personal access token.
-It then sends the token to Galaxy, which in turn verifies that your identity and returns a Galaxy access token. After authentication completes the GitHub token is
+When you choose to use your username and password, your password is not sent to Galaxy. It is used to authenticate with GitHub and create a personal access token.
+It then sends the token to Galaxy, which in turn verifies your identity and returns a Galaxy access token. After authentication completes the GitHub token is
 destroyed.
 
 If you do not wish to use your GitHub password, or if you have two-factor authentication enabled with GitHub, use the *--github-token* option to pass a personal access token

docs/docsite/rst/glossary.rst

@@ -436,7 +436,7 @@ when a term comes up on the mailing list.
         labeled ``ntp``, and then run just the ``ntp`` steps to reconfigure
         the time server information on a remote host.
 
-    Tasks
+    Task
         :term:`Playbooks` exist to run tasks.  Tasks combine an :term:`action`
         (a module and its arguments) with a name and optionally some other
         keywords (like :term:`looping directives <loops>`).   :term:`Handlers`
@@ -444,6 +444,9 @@ when a term comes up on the mailing list.
         unless they are notified by name when a task reports an underlying
         change on a remote system.
 
+    Tasks
+        A list of :term:`Task`.
+
     Templates
         Ansible can easily transfer files to remote systems but often it is
         desirable to substitute variables in other files.  Variables may come

docs/docsite/rst/guide_azure.rst

@@ -40,11 +40,11 @@ There is now a detailed official tutorial describing `how to create a service pr
 
 After stepping through the tutorial you will have:
 
-* Your Client ID, which is found in the “client id” box in the “Configure” page of your application in the Azure portal
+* Your Client ID, which is found in the "client id" box in the "Configure" page of your application in the Azure portal
 * Your Secret key, generated when you created the application. You cannot show the key after creation.
-  If you lost the key, you must create a new one in the “Configure” page of your application.
-* And finally, a tenant ID. It’s a UUID (e.g. ABCDEFGH-1234-ABCD-1234-ABCDEFGHIJKL) pointing to the AD containing your
-  application. You will find it in the URL from within the Azure portal, or in the “view endpoints” of any given URL.
+  If you lost the key, you must create a new one in the "Configure" page of your application.
+* And finally, a tenant ID. It's a UUID (e.g. ABCDEFGH-1234-ABCD-1234-ABCDEFGHIJKL) pointing to the AD containing your
+  application. You will find it in the URL from within the Azure portal, or in the "view endpoints" of any given URL.
 
 
 Using Active Directory Username/Password
@@ -131,14 +131,14 @@ Creating Virtual Machines
 -------------------------
 
 There are two ways to create a virtual machine, both involving the azure_rm_virtualmachine module. We can either create
-a storage account, network interface, security group and public IP address and pass the names of these objects to the
+a storage account, network interface, security group, and public IP address and pass the names of these objects to the
 module as parameters, or we can let the module do the work for us and accept the defaults it chooses.
 
 Creating Individual Components
 ..............................
 
 An Azure module is available to help you create a storage account, virtual network, subnet, network interface,
-security group and public IP. Here is a full example of creating each of these and passing the names to the
+security group, and public IP. Here is a full example of creating each of these and passing the names to the
 azure_rm_virtualmachine module at the end:
 
 .. code-block:: yaml
@@ -315,7 +315,7 @@ azure_rm.ini file in your current working directory.
 NOTE: An .ini file will take precedence over environment variables.
 
 NOTE: The name of the .ini file is the basename of the inventory script (i.e. 'azure_rm') with a '.ini'
-extension. This allows you to copy, rename and customize the inventory script and have matching .ini files all in
+extension. This allows you to copy, rename, and customize the inventory script and have matching .ini files all in
 the same directory.
 
 Control grouping using the following variables defined in the environment:

docs/docsite/rst/guide_cloudstack.rst

@@ -134,7 +134,7 @@ Environment Variables
 `````````````````````
 .. versionadded:: 2.3
 
-Since Ansible 2.3 it is possible to use environment variables for domain (``CLOUDSTACK_DOMAIN``), account (``CLOUDSTACK_ACCOUNT``), project (``CLOUDSTACK_PROJECT``), VPC (``CLOUDSTACK_VPC``) and zone (``CLOUDSTACK_ZONE``). This simplifies the tasks by not repeating the arguments for every tasks.
+Since Ansible 2.3 it is possible to use environment variables for domain (``CLOUDSTACK_DOMAIN``), account (``CLOUDSTACK_ACCOUNT``), project (``CLOUDSTACK_PROJECT``), VPC (``CLOUDSTACK_VPC``), and zone (``CLOUDSTACK_ZONE``). This simplifies the tasks by not repeating the arguments for every tasks.
 
 Below you see an example how it can be used in combination with Ansible's block feature:
 
@@ -165,7 +165,7 @@ Below you see an example how it can be used in combination with Ansible's block
 
 .. Note:: You are still able overwrite the environment variables using the module arguments, e.g. ``zone: sf-2``
 
-.. Note:: Unlike ``CLOUDSTACK_REGION`` these additional environment variables are ingored in the CLI ``cs``.
+.. Note:: Unlike ``CLOUDSTACK_REGION`` these additional environment variables are ignored in the CLI ``cs``.
 
 Use Cases
 `````````
@@ -197,7 +197,7 @@ This is how our inventory looks like:
 
 As you can see, the public IPs for our web servers and jumphost has been assigned as variable ``public_ip`` directly in the inventory.
 
-The configure the jumphost, web servers and database servers, we use ``group_vars``. The ``group_vars`` directory contains 4 files for configuration of the groups: cloud-vm, jumphost, webserver and db-server. The cloud-vm is there for specifying the defaults of our cloud infrastructure.
+To configure the jumphost, web servers, and database servers, we use ``group_vars``. The ``group_vars`` directory contains 4 files for configuration of the groups: cloud-vm, jumphost, webserver, and db-server. The cloud-vm is there for specifying the defaults of our cloud infrastructure.
 
 .. code-block:: yaml
 
@@ -262,9 +262,9 @@ Now to the fun part. We create a playbook to create our infrastructure we call i
           cs_staticnat: vm="{{ inventory_hostname_short }}" ip_address="{{ public_ip }}"
           when: public_ip is defined
 
-In the above play we defined 3 tasks and use the group ``cloud-vm`` as target to handle all VMs in the cloud but instead SSH to these VMs, we use ``connetion=local`` to execute the API calls locally from our workstation.
+In the above play we defined 3 tasks and used the group ``cloud-vm`` as target to handle all VMs in the cloud but instead SSH to these VMs, we use ``connection=local`` to execute the API calls locally from our workstation.
 
-In the first task, we ensure we have a running VM created with the Debian template. If the VM is already created but stopped, it would just start it. If you like to change the offering on an existing VM, you must add ``force: yes`` to the task, which would stop the VM, change the offering and start the VM again.
+In the first task, we ensure we have a running VM created with the Debian template. If the VM is already created but stopped, it would just start it. If you like to change the offering on an existing VM, you must add ``force: yes`` to the task, which would stop the VM, change the offering, and start the VM again.
 
 In the second task we ensure the ports are opened if we give a public IP to the VM.
 
@@ -364,12 +364,12 @@ The playbook looks like the following:
       - name: show VM IP
         debug: msg="VM {{ inventory_hostname }} {{ vm.default_ip }}"
 
-      - name: assing IP to the inventory
+      - name: assign IP to the inventory
         set_fact: ansible_ssh_host={{ vm.default_ip }}
 
       - name: waiting for SSH to come up
         wait_for: port=22 host={{ vm.default_ip }} delay=5
 
-In the first play we setup the security groups, in the second play the VMs will created be assigned to these groups. Further you see, that we assign the public IP returned from the modules to the host inventory. This is needed as we do not know the IPs we will get in advance. In a next step you would configure the DNS servers with these IPs for accassing the VMs with their DNS name.
+In the first play we setup the security groups, in the second play the VMs will created be assigned to these groups. Further you see, that we assign the public IP returned from the modules to the host inventory. This is needed as we do not know the IPs we will get in advance. In a next step you would configure the DNS servers with these IPs for accessing the VMs with their DNS name.
 
 In the last task we wait for SSH to be accessible, so any later play would be able to access the VM by SSH without failure.

docs/docsite/rst/guide_docker.rst

@@ -8,11 +8,11 @@ Ansible offers the following modules for orchestrating Docker containers:
         Swarm. Supports compose versions 1 and 2.
 
     docker_container
-        Manages the container lifecycle by providing the ability to create, update, stop, start and destroy a
+        Manages the container lifecycle by providing the ability to create, update, stop, start, and destroy a
         container.
 
     docker_image
-        Provides full control over images, including: build, pull, push, tag and remove.
+        Provides full control over images, including: build, pull, push, tag, and remove.
 
     docker_image_facts
         Inspects one or more images in the Docker host's image cache, providing the information as facts for making
@@ -126,7 +126,7 @@ running Ansible:
         The maximum amount of time in seconds to wait on a response from the API.
 
     DOCKER_CERT_PATH
-        Path to the directory containing the client certificate, client key and CA certificate.
+        Path to the directory containing the client certificate, client key, and CA certificate.
 
     DOCKER_SSL_VERSION
         Provide a valid SSL version number.
@@ -205,7 +205,7 @@ options. These are the same environment variables used by the Docker modules.
         by docker-py.
 
     DOCKER_TIMEOUT:
-        The maximum amount of time in seconds to wait on a response fromm the API. Defaults to 60 seconds.
+        The maximum amount of time in seconds to wait on a response from the API. Defaults to 60 seconds.
 
     DOCKER_TLS:
         Secure the connection to the API by using TLS without verifying the authenticity of the Docker host server.
@@ -213,18 +213,18 @@ options. These are the same environment variables used by the Docker modules.
 
     DOCKER_TLS_VERIFY:
         Secure the connection to the API by using TLS and verifying the authenticity of the Docker host server.
-        Default is False
+        Defaults to False.
 
     DOCKER_TLS_HOSTNAME:
         When verifying the authenticity of the Docker Host server, provide the expected name of the server. Defaults
         to localhost.
 
     DOCKER_CERT_PATH:
-        Path to the directory containing the client certificate, client key and CA certificate.
+        Path to the directory containing the client certificate, client key, and CA certificate.
 
     DOCKER_SSL_VERSION:
         Provide a valid SSL version number. Default value determined by docker-py, which at the time of this writing
-        was 1.0
+        was 1.0.
 
 In addition to the connection variables there are a couple variables used to control the execution and output of the
 script:

docs/docsite/rst/guide_packet.rst

@@ -8,7 +8,7 @@ Introduction
 `Packet.net <https://packet.net>`_ is a bare metal infrastructure host that's supported by Ansible (>=2.3) via a dynamic inventory script and two cloud modules. The two modules are:
 
 - packet_sshkey: adds a public SSH key from file or value to the Packet infrastructure. Every subsequently-created device will have this public key installed in .ssh/authorized_keys.
-- packet_device: manages servers on Packet. You can use this module to create, restart and delete devices.
+- packet_device: manages servers on Packet. You can use this module to create, restart, and delete devices.
 
 Note, this guide assumes you are familiar with Ansible and how it works. If you're not, have a look at their `docs <http://docs.ansible.com/>`_ before getting started.
 
@@ -183,7 +183,7 @@ The following playbook will create an SSH key, 3 Packet servers, and then wait u
 
 As with most Ansible modules, the default states of the Packet modules are idempotent, meaning the resources in your project will remain the same after re-runs of a playbook. Thus, we can keep the ``packet_sshkey`` module call in our playbook. If the public key is already in your Packet account, the call will have no effect.
 
-The second module call provisions 3 Packet Type 0 (specified using the 'plan' parameter) servers in the project identified via the 'project_id' parameter. The servers are all provisioned with CoresOS beta (the 'operating_system' parameter) and are customized with cloud-config user data passed to the 'user_data' parameter.
+The second module call provisions 3 Packet Type 0 (specified using the 'plan' parameter) servers in the project identified via the 'project_id' parameter. The servers are all provisioned with CoreOS beta (the 'operating_system' parameter) and are customized with cloud-config user data passed to the 'user_data' parameter.
 
 The ``packet_device`` module has a boolean 'wait' parameter that defaults to 'false'. If set to 'true', Ansible will wait until the GET API call for a device will contain an Internet-routeable IP address. The 'wait' parameter allows us to use the IP address of the device as soon as it's available.
 

docs/docsite/rst/guide_rax.rst

@@ -457,7 +457,7 @@ Create an isolated cloud network and build a server
 Complete Environment
 ++++++++++++++++++++
 
-Build a complete webserver environment with servers, custom networks and load balancers, install nginx and create a custom index.html
+Build a complete webserver environment with servers, custom networks and load balancers, install nginx, and create a custom index.html.
 
 .. code-block:: yaml
    

docs/docsite/rst/guide_rolling_upgrade.rst

@@ -176,7 +176,7 @@ Here's another example, from the same template:
    {% endfor %}
 
 This loops over all of the hosts in the group called ``monitoring``, and adds an ACCEPT line for 
-each monitoring hosts' default IPV4 address to the current machine's iptables configuration, so that Nagios can monitor those hosts.
+each monitoring hosts' default IPv4 address to the current machine's iptables configuration, so that Nagios can monitor those hosts.
 
 You can learn a lot more about Jinja2 and its capabilities `here <http://jinja.pocoo.org/docs/>`_, and you 
 can read more about Ansible variables in general in the :doc:`playbooks_variables` section.
@@ -220,6 +220,11 @@ Here is the next part of the update play::
     delegate_to: "{{ item }}"
     with_items: "{{ groups.lbservers }}"
 
+
+.. note::
+   - The ``serial`` keyword forces the play to be executed in 'batches'. Each batch counts as a full play with a subselection of hosts.
+     This has some consequences on play behavior. For example, if all hosts in a batch fails, the play fails, which in turn fails the entire run. You should consider this when combining with ``max_fail_percentage``.
+
 The ``pre_tasks`` keyword just lets you list tasks to run before the roles are called. This will make more sense in a minute. If you look at the names of these tasks, you can see that we are disabling Nagios alerts and then removing the webserver that we are currently updating from the HAProxy load balancing pool.
 
 The ``delegate_to`` and ``with_items`` arguments, used together, cause Ansible to loop over each monitoring server and load balancer, and perform that operation (delegate that operation) on the monitoring or load balancing server, "on behalf" of the webserver. In programming terms, the outer loop is the list of web servers, and the inner loop is the list of monitoring servers.

docs/docsite/rst/guide_vagrant.rst

@@ -113,7 +113,7 @@ single machine environment may look something like this:
 
 If you want to run Ansible manually, you will want to make sure to pass
 ``ansible`` or ``ansible-playbook`` commands the correct arguments, at least
-for the *username*, the *SSH private key* and the *inventory*.
+for the *username*, the *SSH private key*, and the *inventory*.
 
 Here is an example using the Vagrant global insecure key (``config.ssh.insert_key``
 must be set to ``false`` in your ``Vagrantfile``):

docs/docsite/rst/index.rst

@@ -16,7 +16,7 @@ We believe simplicity is relevant to all sizes of environments, so we design for
 Ansible manages machines in an agent-less manner. There is never a question of how to
 upgrade remote daemons or the problem of not being able to manage systems because daemons are uninstalled.  Because OpenSSH is one of the most peer-reviewed open source components, security exposure is greatly reduced. Ansible is decentralized--it relies on your existing OS credentials to control access to remote machines. If needed, Ansible can easily connect with Kerberos, LDAP, and other centralized authentication management systems.
 
-This documentation covers the current released version of Ansible (2.3) and also some development version features (2.4).  For recent features, we note in each section the version of Ansible where the feature was added.
+This documentation covers the current released version of Ansible (2.4) and also some development version features ('devel').  For recent features, we note in each section the version of Ansible where the feature was added.
 
 Ansible, Inc. releases a new major release of Ansible approximately every two months.  The core application evolves somewhat conservatively, valuing simplicity in language design and setup. However, the community around new modules and plugins being developed and contributed moves very quickly, typically adding 20 or so new modules in each release.
 
@@ -32,6 +32,7 @@ Ansible, Inc. releases a new major release of Ansible approximately every two mo
    modules
    modules_by_category
    vault
+   command_line_tools
    guides
    dev_guide/index
    tower

docs/docsite/rst/intro_adhoc.rst

@@ -195,7 +195,7 @@ Deploying From Source Control
 
 Deploy your webapp straight from git::
 
-    $ ansible webservers -m git -a "repo=git://foo.example.org/repo.git dest=/srv/myapp version=HEAD"
+    $ ansible webservers -m git -a "repo=https://foo.example.org/repo.git dest=/srv/myapp version=HEAD"
 
 Since Ansible modules can notify change handlers it is possible to
 tell Ansible to run specific tasks when the code is updated, such as

docs/docsite/rst/intro_bsd.rst

@@ -27,7 +27,7 @@ Bootstrapping BSD
 As mentioned above, you can bootstrap Ansible with the ``raw`` module and remotely install Python on targets. The following example installs Python 2.7 which includes the json library required for full functionality of Ansible.
 On your control machine you can simply execute the following for most versions of FreeBSD::
 
-    ansible -m raw -a “pkg install -y python27” mybsdhost1
+    ansible -m raw -a "pkg install -y python27" mybsdhost1
 
 Once this is done you can now use other Ansible modules apart from the ``raw`` module.
 
@@ -66,7 +66,7 @@ Using BSD as the control machine is as simple as installing the Ansible package
 BSD Facts
 `````````
 
-Ansible gathers facts from the BSDs in a similar manner to Linux machines, but since the data, names and structures can vary for network, disks and other devices, one should expect the output to be slightly different yet still familiar to a BSD administrator.
+Ansible gathers facts from the BSDs in a similar manner to Linux machines, but since the data, names, and structures can vary for network, disks, and other devices, one should expect the output to be slightly different yet still familiar to a BSD administrator.
 
 .. _bsd_contributions:
 

docs/docsite/rst/intro_configuration.rst

@@ -443,7 +443,7 @@ value is a TTL in seconds::
 fact_path
 =========
 
-This option allows you to globally configure a custom path for :ref:`_local_facts`:: for the implied `setup` task when using implied fact gathering.
+This option allows you to globally configure a custom path for :ref:`local_facts` for the implied `setup` task when using implied fact gathering.
 
   fact_path = /home/centos/ansible_facts.d
 
@@ -657,15 +657,15 @@ merge_multiple_cli_tags
 
 .. versionadded:: 2.3
 
-This allows changing how multiple :option:`--tags` and :option:`--skip-tags`
-arguments are handled on the command line.  Specifying :option:`--tags` more
-than once merges all of the :option:`--tags` options together.  If you want
-the pre-2.4.x behaviour where only the last value of :option:`--tags` is used,
-then set this to False.  The same holds true for :option:`--skip-tags`.
+This allows changing how multiple :option:`--tags <ansible-playbook --tags>` and :option:`--skip-tags <ansible-playbook --skip-tags>`
+arguments are handled on the command line.  Specifying :option:`--tags <ansible-playbook --tags>` more
+than once merges all of the :option:`--tags <ansible-playbook --tags>` options together.  If you want
+the pre-2.4.x behaviour where only the last value of :option:`--tags <ansible-playbook --tags>` is used,
+then set this to False.  The same holds true for :option:`--skip-tags <ansible-playbook --skip-tags>`.
 
 .. note:: The default value for this in 2.3 is False.  In 2.4, the
     default value is True.  After 2.8, the option will be removed.
-    Multiple :option:`--tags` and multiple :option:`--skip-tags` will always
+    Multiple :option:`--tags <ansible-playbook --tags>` and multiple :option:`--skip-tags <ansible-playbook --skip-tags>` will always
     be merged together.
 
 .. _module_lang:
@@ -814,26 +814,6 @@ always default to the current user if this is not defined::
     remote_user = root
 
 
-.. _restrict_facts_namespace:
-
-restrict_facts_namespace
-========================
-
-.. versionadded:: 2.4
-
-This allows restricting facts in their own namespace (under ansible_facts) instead of pushing them into the main.
-False by default. Can also be set via the environment variable :envvar:`ANSIBLE_RESTRICT_FACTS`. Using `ansible_system` as an example:
-
-When False::
-
-    - debug: var=ansible_system
-
-
-When True::
-
-    - debug: var=ansible_facts.ansible_system
-
-
 .. _retry_files_enabled:
 
 retry_files_enabled
@@ -1025,7 +1005,7 @@ As of 1.7 this file can also be a script. If you are using a script instead of a
 Privilege Escalation Settings
 -----------------------------
 
-Ansible can use existing privilege escalation systems to allow a user to execute tasks as another. As of 1.9 ‘become’ supersedes the old sudo/su, while still being backwards compatible.  Settings live under the [privilege_escalation] header.
+Ansible can use existing privilege escalation systems to allow a user to execute tasks as another. As of 1.9 'become' supersedes the old sudo/su, while still being backwards compatible.  Settings live under the [privilege_escalation] header.
 
 .. _become:
 

docs/docsite/rst/intro_dynamic_inventory.rst

@@ -185,7 +185,7 @@ Security Group
   ``security_group_Pete_s_Fancy_Group``
 
 Tags
-  Each instance can have a variety of key/value pairs associated with it called Tags. The most common tag key is 'Name', though anything is possible. Each key/value pair is its own group of instances, again with special characters converted to underscores, in the format ``tag_KEY_VALUE``
+  Each instance can have a variety of key/value pairs associated with it called Tags. The most common tag key is 'Name', though anything is possible. Each key/value pair is its own group of instances, again with special characters converted to underscores, in the format ``tag_KEY_VALUE``.
   e.g.
   ``tag_Name_Web`` can be used as is
   ``tag_Name_redis-master-001`` becomes ``tag_Name_redis_master_001``
@@ -265,7 +265,7 @@ Source an OpenStack RC file::
 
 .. note::
 
-    An OpenStack RC file contains the environment variables required by the client tools to establish a connection with the cloud provider, such as the authentication URL, user name, password and region name. For more information on how to download, create or source an OpenStack RC file, please refer to `Set environment variables using the OpenStack RC file <http://docs.openstack.org/user-guide/common/cli_set_environment_variables_using_openstack_rc.html>`_.
+    An OpenStack RC file contains the environment variables required by the client tools to establish a connection with the cloud provider, such as the authentication URL, user name, password, and region name. For more information on how to download, create or source an OpenStack RC file, please refer to `Set environment variables using the OpenStack RC file <http://docs.openstack.org/user-guide/common/cli_set_environment_variables_using_openstack_rc.html>`_.
 
 You can confirm the file has been successfully sourced by running a simple command, such as `nova list` and ensuring it return no errors.
 
@@ -286,13 +286,13 @@ Once you confirm the dynamic inventory script is working as expected, you can te
 Implicit use of inventory script
 ++++++++++++++++++++++++++++++++
 
-Download the latest version of the OpenStack dynamic inventory script, make it executable and copy it to `/etc/ansible/hosts`::
+Download the latest version of the OpenStack dynamic inventory script, make it executable, and copy it to `/etc/ansible/hosts`::
 
     wget https://raw.githubusercontent.com/ansible/ansible/devel/contrib/inventory/openstack.py
     chmod +x openstack.py
     sudo cp openstack.py /etc/ansible/hosts
 
-Download the sample configuration file, modify it to suit your needs and copy it to `/etc/ansible/openstack.yml`::
+Download the sample configuration file, modify it to suit your needs, and copy it to `/etc/ansible/openstack.yml`::
 
     wget https://raw.githubusercontent.com/ansible/ansible/devel/contrib/inventory/openstack.yml
     vi openstack.yml

docs/docsite/rst/intro_installation.rst

@@ -84,7 +84,7 @@ default this uses sftp. If that's not available, you can switch to scp in
    By default, Ansible uses Python 2 in order to maintain compatibility with older distributions
    such as RHEL 6. However, some Linux distributions (Gentoo, Arch) may not have a
    Python 2.X interpreter installed by default.  On those systems, you should install one, and set
-   the 'ansible_python_interpreter' variable in inventory (see :doc:`intro_inventory`) to point at your 2.X Python.  Distributions
+   the ``ansible_python_interpreter`` variable in inventory (see :ref:`inventory`) to point at your 2.X Python.  Distributions
    like Red Hat Enterprise Linux, CentOS, Fedora, and Ubuntu all have a 2.X interpreter installed
    by default and this does not apply to those distributions.  This is also true of nearly all
    Unix systems.
@@ -101,30 +101,38 @@ Installing the Control Machine
 ``````````````````````````````
 .. _from_yum:
 
-Latest Release Via Yum
-++++++++++++++++++++++
+Latest Release via DNF or Yum
++++++++++++++++++++++++++++++
 
-.. note:: We’ve changed how the Ansible community packages are distributed. 
-  For users of RHEL/CentOS/Scientific Linux version 7, the Ansible community RPM
-  package will transition from the EPEL repository to the Extras channel.  There will be no
-  change for version 6 of RHEL/CentOS/Scientific Linux since Extras is not a part of version 6.   
-
-RPMs for RHEL7 are available from `the Extras channel <https://access.redhat.com/solutions/912213>`_.
-
-RPMs for RHEL6 are available from yum for `EPEL
-<http://fedoraproject.org/wiki/EPEL>`_ 6 and currently supported
-Fedora distributions.
-
-Ansible will also have RPMs/YUM-repo available at `<https://releases.ansible.com/ansible/rpms/`.
-
-Ansible version 2.4 can manage earlier operating
-systems that contain Python 2.6 or higher.
-
-You can also build an RPM yourself.  From the root of a checkout or tarball, use the ``make rpm`` command to build an RPM you can distribute and install. 
+On Fedora:
 
 .. code-block:: bash
 
-    $ git clone git://github.com/ansible/ansible.git 
+    $ sudo dnf install ansible
+
+On RHEL and CentOS:
+
+.. code-block:: bash
+
+    $ sudo yum install ansible
+
+RPMs for RHEL 7 are available from the `Ansible Engine repository <https://access.redhat.com/articles/3174981>`_.
+
+To enable the Ansible Engine repository, run the following command:
+
+.. code-block:: bash
+
+    $ sudo subsription-manager repos --enable rhel-7-server-ansible-2.4-rpms
+
+RPMs for currently supported versions of RHEL, CentOS, and Fedora are available from `EPEL <http://fedoraproject.org/wiki/EPEL>`_ as well as `releases.ansible.com <https://releases.ansible.com/ansible/rpm>`_.
+
+Ansible version 2.4 and later can manage earlier operating systems that contain Python 2.6 or higher.
+
+You can also build an RPM yourself. From the root of a checkout or tarball, use the ``make rpm`` command to build an RPM you can distribute and install.
+
+.. code-block:: bash
+
+    $ git clone https://github.com/ansible/ansible.git
     $ cd ./ansible
     $ make rpm
     $ sudo rpm -Uvh ./rpm-build/ansible-*.noarch.rpm
@@ -263,13 +271,13 @@ Then install Ansible with [1]_::
 
 Or if you are looking for the latest development version::
 
-    pip install git+git://github.com/ansible/ansible.git@devel
+    pip install git+https://github.com/ansible/ansible.git@devel
 
 If you are installing on OS X Mavericks, you may encounter some noise from your compiler.  A workaround is to do the following::
 
    $ sudo CFLAGS=-Qunused-arguments CPPFLAGS=-Qunused-arguments pip install ansible
 
-Readers that use virtualenv can also install Ansible under virtualenv, though we'd recommend to not worry about it and just install Ansible globally.  Do not use easy_install to install ansible directly.
+Readers that use virtualenv can also install Ansible under virtualenv, though we'd recommend to not worry about it and just install Ansible globally.  Do not use easy_install to install Ansible directly.
 
 .. _tagged_releases:
 
@@ -305,7 +313,7 @@ To install from source, clone the Ansible git repository:
 
 .. code-block:: bash
 
-    $ git clone git://github.com/ansible/ansible.git --recursive
+    $ git clone https://github.com/ansible/ansible.git --recursive
     $ cd ./ansible
 
 Once git has cloned the Ansible repository, setup the Ansible environment:

docs/docsite/rst/intro_inventory.rst

@@ -11,7 +11,7 @@ which defaults to being saved in the location ``/etc/ansible/hosts``.
 You can specify a different inventory file using the ``-i <path>`` option on the command line.
 
 Not only is this inventory configurable, but you can also use multiple inventory files at the same time and
-pull inventory from dynamic or cloud sources, as described in :doc:`intro_dynamic_inventory`.
+pull inventory from dynamic or cloud sources or different formats (YAML, ini, etc.), as described in :doc:`intro_dynamic_inventory`.
 Introduced in version 2.4, Ansible has inventory plugins to make this flexible and customizable.
 
 .. _inventoryformat:
@@ -38,12 +38,30 @@ For this example, the format for ``/etc/ansible/hosts`` is an INI-like (one of A
 The headings in brackets are group names, which are used in classifying systems
 and deciding what systems you are controlling at what times and for what purpose.
 
+A YAML version would look like:
+
+.. code-block:: yaml
+
+  all:
+    hosts:
+      mail.example.com
+    children:
+      webservers:
+        hosts:
+          foo.example.com:
+          bar.example.com:
+      dbservers:
+        hosts:
+          one.example.com:
+          two.example.com:
+          three.example.com:
+
+
 It is ok to put systems in more than one group, for instance a server could be both a webserver and a dbserver.
 If you do, note that variables will come from all of the groups they are a member of. Variable precedence is detailed in a later chapter.
 
-If you have hosts that run on non-standard SSH ports you can put the port number
-after the hostname with a colon.  Ports listed in your SSH config file won't be used with the `paramiko`
-connection but will be used with the `openssh` connection.
+If you have hosts that run on non-standard SSH ports you can put the port number after the hostname with a colon.
+Ports listed in your SSH config file won't be used with the `paramiko` connection but will be used with the `openssh` connection.
 
 To make things explicit, it is suggested that you set them if things are not running on the default port:
 
@@ -51,20 +69,33 @@ To make things explicit, it is suggested that you set them if things are not run
 
     badwolf.example.com:5309
 
-Suppose you have just static IPs and want to set up some aliases that live in your host file, or you are connecting through tunnels.  You can also describe hosts like this:
+Suppose you have just static IPs and want to set up some aliases that live in your host file, or you are connecting through tunnels.
+You can also describe hosts via variables:
+
+In INI:
 
 .. code-block:: ini
 
     jumper ansible_port=5555 ansible_host=192.0.2.50
 
-In the above example, trying to ansible against the host alias "jumper" (which may not even be a real hostname) will contact 192.0.2.50 on port 5555.  Note that this is using a feature of the inventory file to define some special variables.  Generally speaking this is not the best
-way to define variables that describe your system policy, but we'll share suggestions on doing this later.  We're just getting started.
+In YAML:
 
-.. note:: Values passed in using the ``key=value`` syntax are interpreted as Python literal structure (strings, numbers, tuples, lists, dicts,
-          booleans, None), alternatively as string. For example ``var=FALSE`` would create a string equal to 'FALSE'. Do not rely on types set
-          during definition, always make sure you specify type with a filter when needed when consuming the variable.
+.. code-block:: yaml
 
-Adding a lot of hosts?  If you have a lot of hosts following similar patterns you can do this rather than listing each hostname:
+    hosts:
+      jumper:
+        ansible_port: 5555
+        ansible_host: 192.0.2.50
+
+In the above example, trying to ansible against the host alias "jumper" (which may not even be a real hostname) will contact 192.0.2.50 on port 5555.
+Note that this is using a feature of the inventory file to define some special variables.
+Generally speaking, this is not the best way to define variables that describe your system policy, but we'll share suggestions on doing this later.
+
+.. note:: Values passed in the INI format using the ``key=value`` syntax are not interpreted as Python literal structure
+          (strings, numbers, tuples, lists, dicts, booleans, None), but as a string. For example ``var=FALSE`` would create a string equal to 'FALSE'.
+          Do not rely on types set during definition, always make sure you specify type with a filter when needed when consuming the variable.
+
+If you are adding a lot of hosts following similar patterns, you can do this rather than listing each hostname:
 
 .. code-block:: ini
 
@@ -91,15 +122,14 @@ You can also select the connection type and user on a per host basis:
    other1.example.com     ansible_connection=ssh        ansible_user=mpdehaan
    other2.example.com     ansible_connection=ssh        ansible_user=mdehaan
 
-As mentioned above, setting these in the inventory file is only a shorthand, and we'll discuss how to store them in individual files
-in the 'host_vars' directory a bit later on.
+As mentioned above, setting these in the inventory file is only a shorthand, and we'll discuss how to store them in individual files in the 'host_vars' directory a bit later on.
 
 .. _host_variables:
 
 Host Variables
 ++++++++++++++
 
-As alluded to above, it is easy to assign variables to hosts that will be used later in playbooks:
+As described above, it is easy to assign variables to hosts that will be used later in playbooks:
 
 .. code-block:: ini
 
@@ -112,7 +142,11 @@ As alluded to above, it is easy to assign variables to hosts that will be used l
 Group Variables
 +++++++++++++++
 
-Variables can also be applied to an entire group at once::
+Variables can also be applied to an entire group at once:
+
+The INI way:
+
+.. code-block:: ini
 
    [atlanta]
    host1
@@ -122,14 +156,30 @@ Variables can also be applied to an entire group at once::
    ntp_server=ntp.atlanta.example.com
    proxy=proxy.atlanta.example.com
 
-Be aware that this is only a convenient way to apply variables to multiple hosts at once; even though you can target hosts by group, variables are always flattened to the host level before a play is executed.
+The YAML version:
+
+.. code-block:: yaml
+
+    atlanta:
+      hosts:
+        host1:
+        host2:
+      vars:
+        ntp_server: ntp.atlanta.example.com
+        proxy: proxy.atlanta.example.com
+
+Be aware that this is only a convenient way to apply variables to multiple hosts at once; even though you can target hosts by group, **variables are always flattened to the host level** before a play is executed.
 
 .. _subgroups:
 
 Groups of Groups, and Group Variables
 +++++++++++++++++++++++++++++++++++++
 
-It is also possible to make groups of groups using the ``:children`` suffix. Just like above, you can apply variables using ``:vars``::
+It is also possible to make groups of groups using the ``:children`` suffix in INI or the ``children:`` entry in YAML.
+You can apply variables using ``:vars`` or ``vars:``:
+
+
+.. code-block:: ini
 
    [atlanta]
    host1
@@ -155,11 +205,38 @@ It is also possible to make groups of groups using the ``:children`` suffix. Jus
    southwest
    northwest
 
+.. code-block:: yaml
+
+  all:
+    children:
+      usa:
+        children:
+          southeast:
+            children:
+              atlanta:
+                hosts:
+                  host1:
+                  host2:
+              raleigh:
+                hosts:
+                  host2:
+                  host3:
+            vars:
+              some_server: foo.southeast.example.com
+              halon_system_timeout: 30
+              self_destruct_countdown: 60
+              escape_pods: 2
+         northeast:
+         northwest:
+         southwest:
+
 If you need to store lists or hash data, or prefer to keep host and group specific variables separate from the inventory file, see the next section.
 Child groups have a couple of properties to note:
 
- - First, any host that is member of a child group is automatically a member of the parent group.
- - Second, a child group's variables will have higher precedence (override) a parent group's variables.
+ - Any host that is member of a child group is automatically a member of the parent group.
+ - A child group's variables will have higher precedence (override) a parent group's variables.
+ - Groups can have multiple parents and children, but not circular relationships.
+ - Hosts can also be in multiple groups, but there will only be **one** instance of a host, merging the data from the multiple groups.
 
 .. _default_groups:
 
@@ -168,20 +245,20 @@ Default groups
 
 There are two default groups: ``all`` and ``ungrouped``. ``all`` contains every host.
 ``ungrouped`` contains all hosts that don't have another group aside from ``all``.
+Every host will always belong to at least 2 groups.
+Though ``all`` and ``ungrouped`` are always present, they can be implicit and not appear in group listings like ``group_names``.
 
 .. _splitting_out_vars:
 
 Splitting Out Host and Group Specific Data
 ++++++++++++++++++++++++++++++++++++++++++
 
-The preferred practice in Ansible is actually not to store variables in the main inventory file.
+The preferred practice in Ansible is to not store variables in the main inventory file.
 
-In addition to storing variables directly in the INI file, host
-and group variables can be stored in individual files relative to the
-inventory file.
+In addition to storing variables directly in the inventory file, host and group variables can be stored in individual files relative to the inventory file (not directory, it is always the file).
 
-These variable files are in YAML format. Valid file extensions include '.yml', '.yaml', '.json',
-or no file extension. See :doc:`YAMLSyntax` if you are new to YAML.
+These variable files are in YAML format. Valid file extensions include '.yml', '.yaml', '.json', or no file extension.
+See :doc:`YAMLSyntax` if you are new to YAML.
 
 Assuming the inventory file path is::
 
@@ -202,10 +279,10 @@ the 'raleigh' group might look like::
     ntp_server: acme.example.org
     database_server: storage.example.org
 
-It is ok if these files do not exist, as this is an optional feature.
+It is okay if these files do not exist, as this is an optional feature.
 
-As an advanced use-case, you can create *directories* named after your groups or hosts, and
-Ansible will read all the files in these directories. An example with the 'raleigh' group::
+As an advanced use case, you can create *directories* named after your groups or hosts, and
+Ansible will read all the files in these directories in lexicographical order. An example with the 'raleigh' group::
 
     /etc/ansible/group_vars/raleigh/db_settings
     /etc/ansible/group_vars/raleigh/cluster_settings
@@ -242,7 +319,7 @@ General for all connections:
 ansible_host
     The name of the host to connect to, if different from the alias you wish to give to it.
 ansible_port
-    The ssh port number, if not 22
+    The ssh port number, if not 22.
 ansible_user
     The default ssh user name to use.
 
@@ -250,7 +327,7 @@ ansible_user
 Specific to the SSH connection:
 
 ansible_ssh_pass
-    The ssh password to use (never store this variable in plain text; always use a vault. See :ref:`best_practices_for_variables_and_vaults`)
+    The ssh password to use (never store this variable in plain text; always use a vault. See :ref:`best_practices_for_variables_and_vaults`).
 ansible_ssh_private_key_file
     Private key file used by ssh.  Useful if using multiple keys and you don't want to use SSH agent.
 ansible_ssh_common_args
@@ -272,17 +349,17 @@ ansible_ssh_executable (added in version 2.2)
 Privilege escalation (see :doc:`Ansible Privilege Escalation<become>` for further details):
 
 ansible_become
-    Equivalent to ``ansible_sudo`` or ``ansible_su``, allows to force privilege escalation
+    Equivalent to ``ansible_sudo`` or ``ansible_su``, allows to force privilege escalation.
 ansible_become_method
-    Allows to set privilege escalation method
+    Allows to set privilege escalation method.
 ansible_become_user
-    Equivalent to ``ansible_sudo_user`` or ``ansible_su_user``, allows to set the user you become through privilege escalation
+    Equivalent to ``ansible_sudo_user`` or ``ansible_su_user``, allows to set the user you become through privilege escalation.
 ansible_become_pass
-    Equivalent to ``ansible_sudo_pass`` or ``ansible_su_pass``, allows you to set the privilege escalation password (never store this variable in plain text; always use a vault. See :ref:`best_practices_for_variables_and_vaults`)
+    Equivalent to ``ansible_sudo_pass`` or ``ansible_su_pass``, allows you to set the privilege escalation password (never store this variable in plain text; always use a vault. See :ref:`best_practices_for_variables_and_vaults`).
 ansible_become_exe
-    Equivalent to ``ansible_sudo_exe`` or ``ansible_su_exe``, allows you to set the executable for the escalation method selected
+    Equivalent to ``ansible_sudo_exe`` or ``ansible_su_exe``, allows you to set the executable for the escalation method selected.
 ansible_become_flags
-    Equivalent to ``ansible_sudo_flags`` or ``ansible_su_flags``, allows you to set the flags passed to the selected escalation method. This can be also set globally in :file:`ansible.cfg` in the ``sudo_flags`` option
+    Equivalent to ``ansible_sudo_flags`` or ``ansible_su_flags``, allows you to set the flags passed to the selected escalation method. This can be also set globally in :file:`ansible.cfg` in the ``sudo_flags`` option.
 
 Remote host environment parameters:
 
@@ -307,7 +384,7 @@ ansible_shell_executable
     overrides ``executable`` in :file:`ansible.cfg` which defaults to
     :command:`/bin/sh`.  You should really only change it if is not possible
     to use :command:`/bin/sh` (i.e. :command:`/bin/sh` is not installed on the target
-    machine or cannot be run from sudo.).
+    machine or cannot be run from sudo).
 
 Examples from an Ansible-INI host file::
 
@@ -372,7 +449,7 @@ Here is an example of how to instantly deploy to created containers::
    :doc:`intro_adhoc`
        Examples of basic commands
    :doc:`playbooks`
-       Learning Ansible’s configuration, deployment, and orchestration language.
+       Learning Ansible's configuration, deployment, and orchestration language
    `Mailing List <http://groups.google.com/group/ansible-project>`_
        Questions? Help? Ideas?  Stop by the list on Google Groups
    `irc.freenode.net <http://irc.freenode.net>`_

docs/docsite/rst/intro_networking.rst

@@ -216,5 +216,5 @@ conditional.
 
 The waitfor argument must always start with result and then the
 command index in [], where 0 is the first command in the commands list,
-1 is the second command, 2 is the third and so on.
+1 is the second command, 2 is the third, and so on.
 

docs/docsite/rst/intro_patterns.rst

@@ -58,7 +58,7 @@ is uncommonly used::
 
     webservers:!{{excluded}}:&{{required}}
 
-You also don't have to manage by strictly defined groups.  Individual host names, IPs and groups, can also be referenced using
+You also don't have to manage by strictly defined groups.  Individual host names, IPs, and groups, can also be referenced using
 wildcards
 
 .. code-block:: none

docs/docsite/rst/intro_windows.rst

@@ -59,7 +59,7 @@ Once WSL is enabled, you can open the Bash terminal. At the prompt, you can quic
     # https://github.com/Microsoft/BashOnWindows/issues/816#issuecomment-301216901 for details
     source ~/.profile
 
-After you've successfully run these commands, you can start to create your inventory, write example playbooks and start targeting systems using the plethora of available Windows modules.
+After you've successfully run these commands, you can start to create your inventory, write example playbooks, and start targeting systems using the plethora of available Windows modules.
 
 If you want to run Ansible from source for development purposes, simply uninstall the pip-installed version (which will leave all the necessary dependencies behind), then clone the Ansible source, and run the hacking script to configure it to run from source::
 
@@ -94,7 +94,7 @@ You can specify which authentication option you wish to use by setting it to the
 Certificate
 +++++++++++
 
-Certificate authentication is similar to SSH where a certificate is assigned to a local user and instead of using a password to authenticate a certificate is used instead.
+Certificate authentication is similar to SSH where a certificate is assigned to a local user and instead of using a password to authenticate a certificate is used.
 
 
 Kerberos
@@ -142,7 +142,7 @@ Kerberos is installed and configured by default on OS X and many Linux distribut
 Configuring Kerberos
 --------------------
 
-Edit your /etc/krb5.conf (which should be installed as a result of installing packages above) and add the following information for each domain you need to connect to:
+Edit your `/etc/krb5.conf` (which should be installed as a result of installing packages above) and add the following information for each domain you need to connect to:
 
 In the section that starts with
 
@@ -204,13 +204,13 @@ If you unable to connect using kerberos, check the following:
 
 Ensure that forward and reverse DNS lookups are working properly on your domain.
 
-To test this, ping the windows host you want to control by name then use the ip address returned with nslookup.  You should get the same name back from DNS when you use nslookup on the ip address.  
+To test this, ping the Windows host you want to control by name then use the ip address returned with nslookup.  You should get the same name back from DNS when you use nslookup on the ip address.  
 
 If you get different hostnames back than the name you originally pinged, speak to your active directory administrator and get them to check that DNS Scavenging is enabled and that DNS and DHCP are updating each other.
 
 Ensure that the Ansible controller has a properly configured computer account in the domain.
 
-Check your Ansible controller's clock is synchronised with your domain controller.  Kerberos is time sensitive and a little clock drift can cause tickets not be granted.
+Check your Ansible controller's clock is synchronised with your domain controller.  Kerberos is time sensitive and a little clock drift can cause tickets not to be granted.
 
 Check you are using the real fully qualified domain name for the domain.  Sometimes domains are commonly known to users by aliases.  To check this run:
 
@@ -242,7 +242,7 @@ To install credssp you can use pip to install the requests-credssp library:
 CredSSP and TLS 1.2
 -------------------
 
-CredSSP requires the remote host to have TLS 1.2 configured or else the connection will fail. TLS 1.2 is installed by default from Server 2012 and Windows 8 onwards. For Server 2008, 2008 R2 and Windows 7 you can add TLS 1.2 support by:
+CredSSP requires the remote host to have TLS 1.2 configured or else the connection will fail. TLS 1.2 is installed by default from Server 2012 and Windows 8 onward. For Server 2008, 2008 R2, and Windows 7 you can add TLS 1.2 support by:
 
 * Installing the `TLS 1.2 update from Microsoft <https://support.microsoft.com/en-us/help/3080079/update-to-add-rds-support-for-tls-1.1-and-tls-1.2-in-windows-7-or-windows-server-2008-r2>`_
 * Adding the TLS 1.2 registry keys as shown on this `page <https://technet.microsoft.com/en-us/library/dn786418.aspx#BKMK_SchannelTR_TLS12>`_
@@ -255,7 +255,7 @@ If you need to interact with a remote resource or run a process that requires th
 Inventory
 `````````
 
-Ansible's windows support relies on a few standard variables to indicate the username, password, and connection type (windows) of the remote hosts.  These variables are most easily set up in inventory.  This is used instead of SSH-keys or passwords as normally fed into Ansible::
+Ansible's Windows support relies on a few standard variables to indicate the username, password, and connection type (Windows) of the remote hosts.  These variables are most easily set up in inventory.  This is used instead of SSH-keys or passwords as normally fed into Ansible::
 
     [windows]
     winserver1.example.com
@@ -311,7 +311,7 @@ Since 2.0, the following custom inventory variables are also supported for addit
 Windows System Prep
 ```````````````````
 
-In order for Ansible to manage your windows machines, you will have to enable and configure PowerShell remoting.
+In order for Ansible to manage your Windows machines, you will have to enable and configure PowerShell remoting.
 
 To automate the setup of WinRM, you can run the `examples/scripts/ConfigureRemotingForAnsible.ps1 <https://github.com/ansible/ansible/blob/devel/examples/scripts/ConfigureRemotingForAnsible.ps1>`_ script on the remote machine in a PowerShell console as an administrator.
 
@@ -340,7 +340,7 @@ To troubleshoot the ``ConfigureRemotingForAnsible.ps1`` writes every change it m
    Management Framework 3.0, it may be necessary to install this
    hotfix http://support.microsoft.com/kb/2842230 to avoid receiving
    out of memory and stack overflow exceptions.  Newly-installed Server 2008
-   R2 systems which are not fully up to date with windows updates are known
+   R2 systems which are not fully up to date with Windows updates are known
    to have this issue.
 
    Windows 8.1 and Server 2012 R2 are not affected by this issue as they
@@ -386,9 +386,9 @@ In addition, the following core modules/action-plugins work with Windows:
 * template (also: win_template)
 * wait_for_connection
 
-Some modules can be utilised in playbooks that target windows by delegating to localhost, depending on what you are
+Some modules can be utilised in playbooks that target Windows by delegating to localhost, depending on what you are
 attempting to achieve.  For example, ``assemble`` can be used to create a file on your ansible controller that is then 
-sent to your windows targets using ``win_copy``.
+sent to your Windows targets using ``win_copy``.
 
 In many cases, there is no need to use or write an Ansible module. In particular, the ``script`` module can be used to run arbitrary PowerShell scripts, allowing Windows administrators familiar with PowerShell a very native way to do things, as in the following playbook::
 
@@ -425,7 +425,7 @@ Modules (ps1 files) should start as follows::
 
     # code goes here, reading in stdin as JSON and outputting JSON
 
-The above magic is necessary to tell Ansible to mix in some common code and also know how to push modules out.  The common code contains some nice wrappers around working with hash data structures and emitting JSON results, and possibly a few more useful things.  Regular Ansible has this same concept for reusing Python code - this is just the windows equivalent.
+The above magic is necessary to tell Ansible to mix in some common code and also know how to push modules out.  The common code contains some nice wrappers around working with hash data structures and emitting JSON results, and possibly a few more useful things.  Regular Ansible has this same concept for reusing Python code - this is just the Windows equivalent.
 
 What modules you see in ``windows/`` are just a start.  Additional modules may be submitted as pull requests to github.
 
@@ -434,7 +434,7 @@ What modules you see in ``windows/`` are just a start.  Additional modules may b
 Windows Facts
 `````````````
 
-Just as with Linux/Unix, facts can be gathered for windows hosts, which will return things such as the operating system version.  To see what variables are available about a windows host, run the following::
+Just as with Linux/Unix, facts can be gathered for Windows hosts, which will return things such as the operating system version.  To see what variables are available about a Windows host, run the following::
 
     ansible winhost.example.com -m setup
 

docs/docsite/rst/modules_support.rst

@@ -1,51 +1,50 @@
-Module Support
---------------
+Module Maintenance & Support
+----------------------------
 
 .. toctree:: :maxdepth: 1
 
-Ansible has many modules, but not all of them are maintained by the core project committers. Each module should have associated metadata that indicates which of the following categories they fall into. This should be visible in each module's documentation.
-
-Documentation updates for each module can also be edited directly in the module and by submitting a pull request to the module source code; just look for the "DOCUMENTATION" block in the source tree.
-
-If you believe you have found a bug in a module and are already running the latest stable or development version of Ansible, first look in the `issue tracker at github.com/ansible/ansible <https://github.com/ansible/ansible/issues>`_ to see if a bug has already been filed.  If not, we would be grateful if you would file one.
-
-Should you have a question rather than a bug report, inquiries are welcome on the `ansible-project google group <https://groups.google.com/forum/#!forum/ansible-project>`_ or on Ansible's "#ansible" channel, located on irc.freenode.net.
-
-For development-oriented topics, use the `ansible-devel google group <https://groups.google.com/forum/#!forum/ansible-devel>`_  or Ansible's ``#ansible`` and ``#ansible-devel`` channels, located on irc.freenode.net.  You should also read :doc:`community`, :doc:`dev_guide/testing` and :doc:`dev_guide/developing_modules`.
-
-The modules are hosted on GitHub in a subdirectory of the `ansible <https://github.com/ansible/ansible/tree/devel/lib/ansible/modules>`_ repo.
+To help identify maintainers and understand how the included modules are officially supported, each module now has associated metadata that provides additional clarity for maintenance and support.
 
 Core
 ````
 
-These are :doc:`modules maintained by the Ansible Core Team<core_maintained>`
-and will always ship with Ansible itself.
+:doc:`Core modules are maintained by the Ansible Engineering Team<core_maintained>`.
+These modules are integral to the basic foundations of the Ansible distribution.
 
 Network
 ```````
 
-These are :doc:`modules maintained by the Ansible Network Team<network_maintained>` in a relationship
-similar to how the Ansible Core Team maintains the Core modules.
+:doc:`Network modules are maintained by the Ansible Network Team<network_maintained>`. Please note there are :doc:`additional networking modules<list_of_network_modules>` that are categorized as Certified or Community not maintained by Ansible.
+
 
 Certified
 `````````
 
-Some examples of :doc:`Certified Modules<partner_maintained>` are those submitted by other companies. Maintainers of these types of modules must watch for any issues reported or pull requests raised against the module.
-
-The Ansible Core Team will review all modules becoming certified.  Core committers will review proposed changes to existing Certified Modules once the community maintainers of the module have approved the changes. Core committers will also ensure that any issues that arise due to Ansible engine changes will be remediated.
-Also, it is strongly recommended (but not presently required) for these types of modules to have unit tests.
-
-These modules are currently shipped with Ansible, but might be shipped separately in the future.
+Certified modules are part of a future planned program currently in development.
 
 Community
 `````````
 
-These are :doc:`modules maintained by the Ansible Community<community_maintained>`.  They **are not** supported by the Ansible Core Team or by companies/partners associated to the module.
+:doc:`Community modules are submitted and maintained by the Ansible community<community_maintained>`.  These modules are not maintained by Ansible, and are included as a convenience.
 
-They are still fully usable, but the response rate to issues is purely up to the community.  Best effort support will be provided but is not covered under any support contracts.
+Issue Reporting
+```````````````
 
-These modules are currently shipped with Ansible, but will most likely be shipped separately in the future.
+If you believe you have found a bug in a module and are already running the latest stable or development version of Ansible, first look at the `issue tracker in the Ansible repo <https://github.com/ansible/ansible/issues>`_ to see if an issue has already been filed. If not, please file one.
 
+Should you have a question rather than a bug report, inquiries are welcome on the `ansible-project Google group <https://groups.google.com/forum/#%21forum/ansible-project>`_ or on Ansible's "#ansible" channel, located on irc.freenode.net.
+
+For development-oriented topics, use the `ansible-devel Google group <https://groups.google.com/forum/#%21forum/ansible-devel>`_ or Ansible's #ansible and #ansible-devel channels, located on irc.freenode.net. You should also read :doc:`Community Information & Contributing <community>`, :doc:`Testing Ansible <dev_guide/testing>`, and :doc:`Developing Modules <dev_guide/developing_modules>`.
+
+The modules are hosted on GitHub in a subdirectory of the `Ansible <https://github.com/ansible/ansible/tree/devel/lib/ansible/modules>`_ repo.
+
+NOTE: If you have a Red Hat Ansible Engine product subscription, please follow the standard issue reporting process via the Red Hat Customer Portal.
+
+Support
+```````
+
+For more information on how included Ansible modules are supported by Red Hat,
+please refer to the following `knowledgebase article <https://access.redhat.com/articles/3166901>`_ as well as other resources on the `Red Hat Customer Portal. <https://access.redhat.com/>`_
 
 .. seealso::
 

docs/docsite/rst/network_debug_troubleshooting.rst

@@ -32,7 +32,7 @@ Errors generally fall into one of the following categories:
   * Can occur when trying to pull a large amount of data
   * May actually be masking a authentication issue
 :Playbook issues:
-  * Use of ``delegate_to``, instead of ``ProxyCommand``
+  * Use of ``delegate_to``, instead of ``ProxyCommand``. See :ref:`network proxy guide <network_delegate_to_vs_ProxyCommand>` for more information.
   * Not using ``connection: local``
 
 
@@ -51,7 +51,9 @@ Enabling Networking logging and how to read the logfile
 
 Ansible 2.3 features improved logging to help diagnose and troubleshoot issues regarding Ansible Networking modules.
 
-Because logging is very verbose it is disabled by default. It can be enabled via the :envvar:`ANSIBLE_LOG_PATH` and :envvar:`ANISBLE_DEBUG` options::
+Because logging is very verbose it is disabled by default. It can be enabled via the :envvar:`ANSIBLE_LOG_PATH` and :envvar:`ANSIBLE_DEBUG` options on the ansible-controller, that is the machine running ansible-playbook.
+
+Before running ``ansible-playbook`` run the following commands to enable logging::
 
    # Specify the location for the log file
    export ANSIBLE_LOG_PATH=~/ansible.log
@@ -61,10 +63,12 @@ Because logging is very verbose it is disabled by default. It can be enabled via
    # Run with 4*v for connection level verbosity
    ansible-playbook -vvvv ...
 
-After Ansible has finished running you can inspect the log file:
+After Ansible has finished running you can inspect the log file which has been created on the ansible-controller:
 
 .. code::
 
+  less $ANSIBLE_LOG_PATH
+
   2017-03-30 13:19:52,740 p=28990 u=fred |  creating new control socket for host veos01:22 as user admin
   2017-03-30 13:19:52,741 p=28990 u=fred |  control socket path is /home/fred/.ansible/pc/ca5960d27a
   2017-03-30 13:19:52,741 p=28990 u=fred |  current working directory is /home/fred/ansible/test/integration
@@ -410,10 +414,10 @@ For example:
 
 Suggestions to resolve:
 
-Increase value of presistent connection idle timeout.
-Note: This value should be greater than SSH timeout ie. timeout value under defaults
-section in configuration file and less than the value of the persistent
-connection idle timeout (connect_timeout)
+Increase the value of the persistent connection idle timeout.
+Note: This value should be greater than the SSH timeout value (the timeout value under the defaults
+section in the configuration file) and less than the value of the persistent
+connection idle timeout (connect_timeout).
 
 .. code-block:: yaml
 
@@ -493,7 +497,7 @@ Add ``authorize: yes`` to the task. For example:
 If the user requires a password to go into privileged mode, this can be specified with ``auth_pass``; if ``auth_pass`` isn't set, the environment variable :envvar:`ANSIBLE_NET_AUTHORIZE` will be used instead.
 
 
-Add `authorize: yes` to the task. For example:
+Add ``authorize: yes`` to the task. For example:
 
 .. code-block:: yaml
 
@@ -506,40 +510,41 @@ Add `authorize: yes` to the task. For example:
   register: result
 
 
-.. delete_to not honoured
-   ----------------------
+Proxy Issues
+============
 
-   FIXME Do we get an error message
+ .. _network_delegate_to_vs_ProxyCommand:
 
-   FIXME Link to howto
+delegate_to vs ProxyCommand
+---------------------------
+
+The new connection framework for Network Modules in Ansible 2.3 that uses ``cli`` transport
+no longer supports the use of the ``delegate_to`` directive.
+In order to use a bastion or intermediate jump host to connect to network devices over ``cli``
+transport, network modules now support the use of ``ProxyCommand``.
+
+To use ``ProxyCommand``, configure the proxy settings in the Ansible inventory
+file to specify the proxy host.
+
+.. code-block:: ini
+
+    [nxos]
+    nxos01
+    nxos02
+
+    [nxos:vars]
+    ansible_ssh_common_args='-o ProxyCommand="ssh -W %h:%p -q bastion01"'
 
 
+With the configuration above, simply build and run the playbook as normal with
+no additional changes necessary.  The network module will now connect to the
+network device by first connecting to the host specified in
+``ansible_ssh_common_args``, which is ``bastion01`` in the above example.
 
 
-   fixmes
-   ======
+.. note:: Using ``ProxyCommand`` with passwords via variables
 
-   Error: "number of connection attempts exceeded, unable to connect to control socket"
-   ------------------------------------------------------------------------------------
+   By design, SSH doesn't support providing passwords via environment variables.
+   This is done to prevent secrets from leaking out, for example in ``ps`` output.
 
-   **Platforms:** Any
-
-   This occurs when Ansible wasn't able to connect to the remote device and obtain a shell with the timeout.
-
-
-   This information is available when :ref:`DEFAULT_LOG_PATH` is set see (FIXMELINKTOSECTION):
-
-   .. code-block:: yaml
-
-     less $ANSIBLE_LOG_PATH
-     2017-03-10 15:32:06,173 p=19677 u=fred |  connect retry timeout expired, unable to connect to control socket
-     2017-03-10 15:32:06,174 p=19677 u=fred |  persistent_connect_retry_timeout is 15 secs
-     2017-03-10 15:32:06,222 p=19669 u=fred |  fatal: [veos01]: FAILED! => {
-
-   Suggestions to resolve:
-
-   Do stuff For example:
-
-   .. code-block:: yaml
-
-   	Example stuff
+   We recommend using SSH Keys, and if needed an ssh-agent, rather than passwords, where ever possible.

docs/docsite/rst/playbooks_async.rst

@@ -94,7 +94,7 @@ of tasks running concurrently, you can do it this way::
           - 4
           - 5
         durations: "{{ item }}"
-      include: execute_batch.yml
+      include_tasks: execute_batch.yml
       with_items:
         - "{{ sleep_durations | batch(2) | list }}"
 

docs/docsite/rst/playbooks_best_practices.rst

@@ -216,15 +216,15 @@ variables from the file "group_vars/ec2_tag_class_webserver" automatically.
 Top Level Playbooks Are Separated By Role
 `````````````````````````````````````````
 
-In site.yml, we include a playbook that defines our entire infrastructure.  Note this is SUPER short, because it's just including
-some other playbooks.  Remember, playbooks are nothing more than lists of plays::
+In site.yml, we import a playbook that defines our entire infrastructure.  This is a very short example, because it's just importing
+some other playbooks::
 
     ---
     # file: site.yml
-    - include: webservers.yml
-    - include: dbservers.yml
+    - import_playbook: webservers.yml
+    - import_playbook: dbservers.yml
 
-In a file like webservers.yml (also at the top level), we simply map the configuration of the webservers group to the roles performed by the webservers group.  Also notice this is incredibly short.  For example::
+In a file like webservers.yml (also at the top level), we map the configuration of the webservers group to the roles performed by the webservers group::
 
     ---
     # file: webservers.yml

docs/docsite/rst/playbooks_conditionals.rst

@@ -154,13 +154,13 @@ there will be accessible to future tasks::
 
 .. _when_roles_and_includes:
 
-Applying 'when' to roles and includes
-`````````````````````````````````````
+Applying 'when' to roles, imports, and includes
+```````````````````````````````````````````````
 
 Note that if you have several tasks that all share the same conditional statement, you can affix the conditional
 to a task include statement as below.  All the tasks get evaluated, but the conditional is applied to each and every task::
 
-    - include: tasks/sometasks.yml
+    - import_tasks: tasks/sometasks.yml
       when: "'reticulating splines' in output"
 
 .. note:: In versions prior to 2.0 this worked with task includes but not playbook includes.  2.0 allows it to work with both.
@@ -174,6 +174,24 @@ Or with a role::
 You will note a lot of 'skipped' output by default in Ansible when using this approach on systems that don't match the criteria.
 Read up on the 'group_by' module in the :doc:`modules` docs for a more streamlined way to accomplish the same thing.
 
+When used with `include_*` tasks instead of imports, the conditional is applied _only_ to the include task itself and not any other
+tasks within the included file(s). A common situation where this distinction is important is as follows::
+
+    # include a file to define a variable when it is not already defined
+
+    # main.yml
+    - include_tasks: other_tasks.yml
+      when: x is not defined
+
+    # other_tasks.yml
+    - set_fact:
+        x: foo
+    - debug:
+        var: x
+
+In the above example, if ``import_tasks`` had been used instead both included tasks would have also been skipped. With ``include_tasks``
+instead, the tasks are executed as expected because the conditional is not applied to them.
+
 .. _conditional_imports:
 
 Conditional Imports

docs/docsite/rst/playbooks_filters.rst

@@ -155,26 +155,26 @@ To get a random item from a list::
     "{{ ['a','b','c']|random }}"
     # => 'c'
 
-To get a random number from 0 to supplied end::
+To get a random number between 0 and a specified number::
 
-    "{{ 59 |random}} * * * * root /script/from/cron"
+    "{{ 60 |random}} * * * * root /script/from/cron"
     # => '21 * * * * root /script/from/cron'
 
 Get a random number from 0 to 100 but in steps of 10::
 
-    {{ 100 |random(step=10) }}
+    {{ 101 |random(step=10) }}
     # => 70
 
 Get a random number from 1 to 100 but in steps of 10::
 
-    {{ 100 |random(1, 10) }}
+    {{ 101 |random(1, 10) }}
     # => 31
-    {{ 100 |random(start=1, step=10) }}
+    {{ 101 |random(start=1, step=10) }}
     # => 51
 
 As of Ansible version 2.3, it's also possible to initialize the random number generator from a seed. This way, you can create random-but-idempotent numbers::
 
-    "{{ 59 |random(seed=inventory_hostname) }} * * * * root /script/from/cron"
+    "{{ 60 |random(seed=inventory_hostname) }} * * * * root /script/from/cron"
 
 
 Shuffle Filter
@@ -695,11 +695,11 @@ To add quotes for shell usage::
 
 To use one value on true and another on false (new in version 1.9)::
 
-   {{ (name == "John") | ternary('Mr','Ms') }}
+    {{ (name == "John") | ternary('Mr','Ms') }}
 
 To concatenate a list into a string::
 
-   {{ list | join(" ") }}
+    {{ list | join(" ") }}
 
 To get the last name of a file path, like 'foo.txt' out of '/etc/asdf/foo.txt'::
 
@@ -735,7 +735,7 @@ To expand a path containing a tilde (`~`) character (new in version 1.5)::
 
 To get the real path of a link (new in version 1.8)::
 
-   {{ path | realpath }}
+    {{ path | realpath }}
 
 To get the relative path of a link, from a start point (new in version 1.7)::
 

docs/docsite/rst/playbooks_intro.rst

@@ -345,7 +345,7 @@ a variable called ``vhost`` in the ``vars`` section, you could do this::
 Those same variables are usable in templates, which we'll get to later.
 
 Now in a very basic playbook all the tasks will be listed directly in that play, though it will usually
-make more sense to break up tasks using the ``include:`` directive.  We'll show that a bit later.
+make more sense to break up tasks as described in :doc:`playbooks_reuse`.
 
 .. _action_shorthand:
 
@@ -458,7 +458,7 @@ Let's run a playbook using a parallelism level of 10::
 
     ansible-playbook playbook.yml -f 10
 
-.. _ansible-pull:
+.. _playbook_ansible-pull:
 
 Ansible-Pull
 ````````````

docs/docsite/rst/playbooks_lookups.rst

@@ -458,7 +458,7 @@ Please check https://api.mongodb.org/python/current/api/pymongo/collection.html?
 
 Since there are too many parameters for this lookup method, below is a sample playbook which shows its usage and a nice way to feed the parameters:
 
-.. code-block:: YAML+Jinja
+.. code-block:: yaml
 
     ---
     - hosts: all

docs/docsite/rst/playbooks_loops.rst

@@ -743,7 +743,7 @@ Ansible by default sets the loop variable `item` for each loop, which causes the
 As of Ansible 2.1, the `loop_control` option can be used to specify the name of the variable to be used for the loop::
 
     # main.yml
-    - include: inner.yml
+    - include_tasks: inner.yml
       with_items:
         - 1
         - 2
@@ -807,7 +807,7 @@ Because `loop_control` is not available in Ansible 2.0, when using an include wi
 for `item`::
 
     # main.yml
-    - include: inner.yml
+    - include_tasks: inner.yml
       with_items:
         - 1
         - 2

docs/docsite/rst/playbooks_prompts.rst

@@ -27,8 +27,9 @@ Here is a most basic example::
         - name: "favcolor"
           prompt: "what is your favorite color?"
 
+
 .. note::
-   Prompts for individual ``vars_prompt`` variables will be skipped for any variable that is already defined through the command line ``--extra-vars`` option, or when running from a non-interactive session (such as cron or Ansible Tower). See :ref:`_passing_variables_on_the_command_line` in the /Variables/ chapter.
+    Prompts for individual ``vars_prompt`` variables will be skipped for any variable that is already defined through the command line ``--extra-vars`` option, or when running from a non-interactive session (such as cron or Ansible Tower). See :ref:`passing_variables_on_the_command_line` in the /Variables/ chapter.
 
 If you have a variable that changes infrequently, it might make sense to
 provide a default value that can be overridden.  This can be accomplished using
@@ -77,13 +78,13 @@ You can use any crypt scheme supported by 'Passlib':
 - *sun_md5_crypt* - Sun MD5 Crypt
 - *sha256_crypt* - SHA-256 Crypt
 - *sha512_crypt* - SHA-512 Crypt
-- *apr_md5_crypt* - Apache’s MD5-Crypt variant
-- *phpass* - PHPass’ Portable Hash
+- *apr_md5_crypt* - Apache's MD5-Crypt variant
+- *phpass* - PHPass' Portable Hash
 - *pbkdf2_digest* - Generic PBKDF2 Hashes
-- *cta_pbkdf2_sha1* - Cryptacular’s PBKDF2 hash
-- *dlitz_pbkdf2_sha1* - Dwayne Litzenberger’s PBKDF2 hash
+- *cta_pbkdf2_sha1* - Cryptacular's PBKDF2 hash
+- *dlitz_pbkdf2_sha1* - Dwayne Litzenberger's PBKDF2 hash
 - *scram* - SCRAM Hash
-- *bsd_nthash* - FreeBSD’s MCF-compatible nthash encoding
+- *bsd_nthash* - FreeBSD's MCF-compatible nthash encoding
 
 However, the only parameters accepted are 'salt' or 'salt_size'. You can use your own salt using
 'salt', or have one generated automatically using 'salt_size'. If nothing is specified, a salt

docs/docsite/rst/playbooks_reuse.rst

@@ -9,10 +9,12 @@ Creating Reusable Playbooks
 
 While it is possible to write a playbook in one very large file (and you might start out learning playbooks this way), eventually you'll want to reuse files and start to organize things. In Ansible, there are three ways to do this: includes, imports, and roles.
 
-Includes and imports allow users to break up large playbooks into smaller files, which can be used across multiple parent playbooks or even multiple times within the same Playbook.
+Includes and imports (added in 2.4) allow users to break up large playbooks into smaller files, which can be used across multiple parent playbooks or even multiple times within the same Playbook.
 
 Roles allow more than just tasks to be packaged together and can include variables, handlers, or even modules and other plugins. Unlike includes and imports, roles can also be uploaded and shared via Ansible Galaxy.
 
+.. _dynamic_vs_static:
+
 Dynamic vs. Static
 ``````````````````
 
@@ -50,8 +52,8 @@ The primary advantage of using ``include*`` statements is looping. When a loop i
 
 Using ``include*`` does have some limitations when compared to ``import*`` statements:
 
-* Tags which only exist inside a dynamic include will not show up in --list-tags output.
-* Tasks which only exist inside a dynamic include will not show up in --list-tasks output.
+* Tags which only exist inside a dynamic include will not show up in ``--list-tags`` output.
+* Tasks which only exist inside a dynamic include will not show up in ``--list-tasks`` output.
 * You cannot use ``notify`` to trigger a handler name which comes from inside a dynamic include (see note below).
 * You cannot use ``--start-at-task`` to begin execution at a task inside a dynamic include.
 

docs/docsite/rst/playbooks_reuse_includes.rst

@@ -13,17 +13,25 @@ As noted in :doc:`playbooks_reuse`, include and import statements are very simil
 
 Please refer to  :doc:`playbooks_reuse` for documentation concerning the trade-offs one may encounter when using each type.
 
+Also be aware that this behaviour changed in 2.4; prior to that Ansible version only ``include`` was available, and it behaved differently depending on context.
+
+.. versionadded:: 2.4
+
 Importing Playbooks
 ```````````````````
 
 It is possible to include playbooks inside a master playbook. For example::
 
     ---
-    import_playbook: webservers.yml
-    import_playbook: databases.yml
+    - import_playbook: webservers.yml
+    - import_playbook: databases.yml
 
-Each playbook listed will be run in the order they are listed.
+The plays and tasks in each playbook listed will be run in the order they are listed, just as if they had been defined here directly.
 
+Prior to 2.4 only ``include`` was available and worked for both playbooks and tasks as both import and include.
+
+
+.. versionadded:: 2.4
 
 Including and Importing Task Files
 ``````````````````````````````````
@@ -61,7 +69,7 @@ Variables can also be passed to include files using an alternative syntax, which
         - "{{ lookup('file', 'keys/one.pub') }}"
         - "{{ lookup('file', 'keys/two.pub') }}"
 
-Using either syntax, variables passed in can then be used in the included files. These variables will only be available to tasks within the included file. See :doc:`variable_precedence` for more details on variable inheritance and precedence.
+Using either syntax, variables passed in can then be used in the included files. These variables will only be available to tasks within the included file. See :ref:`variable_precedence` for more details on variable inheritance and precedence.
 
 Task include statements can be used at arbitrary depth.
 

docs/docsite/rst/playbooks_reuse_roles.rst

@@ -33,8 +33,8 @@ Roles expect files to be in certain directory names. Roles must include at least
 
 - ``tasks`` - contains the main list of tasks to be executed by the role.
 - ``handlers`` - contains handlers, which may be used by this role or even anywhere outside this role.
-- ``defaults`` - default variables for the role (see :doc:`Variables` for more information).
-- ``vars`` - other variables for the role (see :doc:`Variables` for more information).
+- ``defaults`` - default variables for the role (see :doc:`playbooks_variables` for more information).
+- ``vars`` - other variables for the role (see :doc:`playbooks_variables` for more information).
 - ``files`` - contains files which can be deployed via this role.
 - ``templates`` - contains templates which can be deployed via this role.
 - ``meta`` - defines some meta data for this role. See below for more details.
@@ -42,7 +42,8 @@ Roles expect files to be in certain directory names. Roles must include at least
 Other YAML files may be included in certain directories. For example, it is common practice to have platform-specific tasks included from the ``tasks/main.yml`` file::
 
     # roles/example/tasks/main.yml
-    - import_tasks: redhat.yml
+    - name: added in 2.4, previouslly you used 'include'
+      import_tasks: redhat.yml
       when: ansible_os_platform|lower == 'redhat'
     - import_tasks: debian.yml
       when: ansible_os_platform|lower == 'debian'
@@ -57,7 +58,7 @@ Other YAML files may be included in certain directories. For example, it is comm
         name: "apache2"
         state: present
 
-Roles may also include modules and other plugin types. For more information, please refer to the :doc:`Embedding Modules and Plugins In Roles` section below.
+Roles may also include modules and other plugin types. For more information, please refer to the :ref:`embedding_modules_and_plugins_in_roles` section below.
 
 Using Roles
 ```````````
@@ -113,9 +114,9 @@ As of Ansible 2.4, you can now use roles inline with any other tasks using ``imp
 When roles are defined in the classic manner, they are treated as static imports and processed during playbook parsing.
 
 .. note::
-    The ``include_role`` option was introduced in Ansible 2.3. The usage has changed slightly as of Ansible 2.4 to match the include (dynamic) vs. import (static) usage. See :doc:`Dynamic vs. Static` for more details.
+    The ``include_role`` option was introduced in Ansible 2.3. The usage has changed slightly as of Ansible 2.4 to match the include (dynamic) vs. import (static) usage. See :ref:`dynamic_vs_static` for more details.
 
-The name used for the role can be a simple name (see :doc:`Role Search Path` below), or it can be a fully qualified path::
+The name used for the role can be a simple name (see :ref:`role_search_path` below), or it can be a fully qualified path::
 
     ---
 
@@ -197,7 +198,7 @@ To make roles run more than once, there are two options:
 1. Pass different parameters in each role definition.
 2. Add ``allow_duplicates: true`` to the ``meta/main.yml`` file for the role.
 
-Example 1 - passing different paramters::
+Example 1 - passing different parameters::
 
     ---
     - hosts: webservers
@@ -290,6 +291,8 @@ Note that we did not have to use ``allow_duplicates: true`` for ``wheel``, becau
 .. note::
    Variable inheritance and scope are detailed in the :doc:`playbooks_variables`.
 
+.. _embedding_modules_and_plugins_in_roles:
+
 Embedding Modules and Plugins In Roles
 ``````````````````````````````````````
 
@@ -332,6 +335,8 @@ The same mechanism can be used to embed and distribute plugins in a role, using
 
 They can then be used in a template or a jinja template in any role called after 'my_custom_filter'
 
+.. _role_search_path:
+
 Role Search Path
 ````````````````
 

docs/docsite/rst/playbooks_tags.rst

@@ -80,9 +80,14 @@ You may also apply tags to roles::
     roles:
       - { role: webserver, port: 5000, tags: [ 'web', 'foo' ] }
 
-And include statements::
+And import/include statements::
 
-    - include: foo.yml
+    - import_tasks: foo.yml
+      tags: [web,foo]
+
+or::
+
+    - include_tasks: foo.yml
       tags: [web,foo]
 
 All of these apply the specified tags to EACH task inside the play, included

docs/docsite/rst/playbooks_variables.rst

@@ -836,13 +836,16 @@ In 2.x, we have made the order of precedence more specific (with the last listed
 
   * role defaults [1]_
   * inventory file or script group vars [2]_
-  * inventory group_vars/all
-  * playbook group_vars/all
-  * inventory group_vars/*
-  * playbook group_vars/*
+  * inventory group_vars/all [3]_
+  * playbook group_vars/all [3]_
+  * inventory group_vars/* [3]_
+  * playbook group_vars/* [3]_
   * inventory file or script host vars [2]_
   * inventory host_vars/*
   * playbook host_vars/*
+  * host facts / cached set_facts [4]_
+  * inventory host_vars/* [3]_
+  * playbook host_vars/* [3]_
   * host facts
   * play vars
   * play vars_prompt
@@ -862,6 +865,9 @@ Basically, anything that goes into "role defaults" (the defaults folder inside t
 
 .. [1] Tasks in each role will see their own role's defaults. Tasks defined outside of a role will see the last role's defaults.
 .. [2] Variables defined in inventory file or provided by dynamic inventory.
+.. [3] Includes vars added by 'vars plugins' as well as host_vars and group_vars which are added by the default vars plugin shipped with Ansible.
+.. [4] When created with set_facts's cacheable option, variables will have the high precedence in the play,
+       but will be the same as a host facts precedence when they come from the cache.
 
 .. note:: Within any section, redefining a var will overwrite the previous instance.
           If multiple groups have the same variable, the last one loaded wins.

docs/docsite/rst/playbooks_vault.rst

@@ -3,9 +3,9 @@ Using Vault in playbooks
 
 .. contents:: Topics
 
-New in Ansible 1.5, "Vault" is a feature of ansible that allows keeping sensitive data such as passwords or keys in encrypted files, rather than as plaintext in your playbooks or roles. These vault files can then be distributed or placed in source control.
+Added in Ansible 1.5, "Vault" is a feature of ansible that allows keeping sensitive data such as passwords or keys in encrypted files, rather than as plaintext in your playbooks or roles. These vault files can then be distributed or placed in source control.
 
-To enable this feature, a command line tool, `ansible-vault` is used to edit files, and a command line flag `--ask-vault-pass` or `--vault-password-file` is used. Alternately, you may specify the location of a password file or command Ansible to always prompt for the password in your ansible.cfg file. These options require no command line flag usage.
+To enable this feature, a command line tool, :ref:`ansible-vault` is used to edit files, and a command line flag :option:`--ask-vault-pass <ansible-vault --ask-vault-pass>` or :option:`--vault-password-file <ansible-vault --vault-password-file>` is used. You can also modify your ``ansible.cfg`` file to specify the location of a password file or configure Ansible to always prompt for the password. These options require no command line flag usage.
 
 For best practices advice, refer to :ref:`best_practices_for_variables_and_vaults`.
 
@@ -35,7 +35,7 @@ If you are using a script instead of a flat file, ensure that it is marked as ex
 
 This is something you may wish to do if using Ansible from a continuous integration system like Jenkins.
 
-(The `--vault-password-file` option can also be used with the :ref:`ansible-pull` command if you wish, though this would require distributing the keys to your nodes, so understand the implications -- vault is more intended for push mode).
+The :option:`--vault-password-file <ansible-pull --vault-password-file>` option can also be used with the :ref:`ansible-pull` command if you wish, though this would require distributing the keys to your nodes, so understand the implications -- vault is more intended for push mode.
 
 
 .. _single_encrypted_variable:
@@ -55,7 +55,7 @@ As of version 2.3, Ansible can now use a vaulted variable that lives in an other
               34623731376664623134383463316265643436343438623266623965636363326136
     other_plain_text: othervalue
 
-To create a vaulted variable, use the :ref:`ansible-vault encrypt_string` command. See :ref:`encrypt_string` for details.
+To create a vaulted variable, use the :ref:`ansible-vault encrypt_string <ansible_vault_encrypt_string>` command. See :ref:`encrypt_string` for details.
 
 This vaulted variable will be decrypted with the supplied vault secret and used as a normal variable. The ``ansible-vault`` command line supports stdin and stdout for encrypting data on the fly, which can be used from your favorite editor to create these vaulted variables; you just have to be sure to add the ``!vault`` tag so both Ansible and YAML are aware of the need to decrypt. The ``|`` is also required, as vault encryption results in a multi-line string.
 
@@ -66,6 +66,6 @@ Using encrypt_string
 ````````````````````
 
 This command will output a string in the above format ready to be included in a YAML file.
-The string to encrypt can be provided via stdin, command line args, or via an interactive prompt.
+The string to encrypt can be provided via stdin, command line arguments, or via an interactive prompt.
 
 See :ref:`encrypt_string_for_use_in_yaml`.

docs/docsite/rst/porting_guide_2.0.rst

@@ -109,7 +109,7 @@ While all items listed here will show a deprecation warning message, they still
 
 * Bare variables in ``with_`` loops should instead use the ``"{ {var }}"`` syntax, which helps eliminate ambiguity.
 * The ansible-galaxy text format requirements file. Users should use the YAML format for requirements instead.
-* Undefined variables within a ``with_`` loop’s list currently do not interrupt the loop, but they do issue a warning; in the future, they will issue an error.
+* Undefined variables within a ``with_`` loop's list currently do not interrupt the loop, but they do issue a warning; in the future, they will issue an error.
 * Using dictionary variables to set all task parameters is unsafe and will be removed in a future version. For example::
 
     - hosts: localhost
@@ -129,8 +129,8 @@ While all items listed here will show a deprecation warning message, they still
 
 * Host patterns should use a comma (,) or colon (:) instead of a semicolon (;) to separate hosts/groups in the pattern.
 * Ranges specified in host patterns should use the [x:y] syntax, instead of [x-y].
-* Playbooks using privilege escalation should always use “become*” options rather than the old su*/sudo* options.
-* The “short form” for vars_prompt is no longer supported.
+* Playbooks using privilege escalation should always use "become*" options rather than the old su*/sudo* options.
+* The "short form" for vars_prompt is no longer supported.
   For example::
 
     vars_prompt:
@@ -138,28 +138,28 @@ While all items listed here will show a deprecation warning message, they still
 
 * Specifying variables at the top level of a task include statement is no longer supported. For example::
 
-    - include: foo.yml
+    - include_tasks: foo.yml
         a: 1
 
 Should now be::
 
-    - include: foo.yml
+    - include_tasks: foo.yml
       vars:
         a: 1
 
 * Setting any_errors_fatal on a task is no longer supported. This should be set at the play level only.
-* Bare variables in the `environment` dictionary (for plays/tasks/etc.) are no longer supported. Variables specified there should use the full variable syntax: ‘{{foo}}’.
+* Bare variables in the `environment` dictionary (for plays/tasks/etc.) are no longer supported. Variables specified there should use the full variable syntax: '{{foo}}'.
 * Tags (or any directive) should no longer be specified with other parameters in a task include. Instead, they should be specified as an option on the task.
   For example::
 
-    - include: foo.yml tags=a,b,c
+    - include_tasks: foo.yml tags=a,b,c
 
   Should be::
 
-    - include: foo.yml
+    - include_tasks: foo.yml
       tags: [a, b, c]
 
-* The first_available_file option on tasks has been deprecated. Users should use the with_first_found option or lookup (‘first_found’, …) plugin.
+* The first_available_file option on tasks has been deprecated. Users should use the with_first_found option or lookup ('first_found', …) plugin.
 
 
 Other caveats
@@ -171,7 +171,7 @@ Here are some corner cases encountered when updating. These are mostly caused by
 
     with_items: myvar_{{rest_of_name}}
 
-  This worked 'by accident' as the errors were retemplated and ended up resolving the variable, it was never intended as valid syntax and now properly returns an error, use the following instead.::
+  This worked 'by accident' as the errors were retemplated and ended up resolving the variable, it was never intended as valid syntax and now properly returns an error, use the following instead::
 
     hostvars[inventory_hostname]['myvar_' + rest_of_name]
 
@@ -287,7 +287,7 @@ Since the ansible-2.0 plugin system is more advanced, it is easier to adapt your
 
 You may find the following tips useful:
 
-* Check whether the ansible-2.0 class(es) are available and if they are missing (ansible-1.9.x) mimic them with the needed methods (e.g. ``__init__``)
+* Check whether the ansible-2.0 class(es) are available and if they are missing (ansible-1.9.x) mimic them with the needed methods (e.g. ``__init__``).
 
 * When ansible-2.0 python modules are imported, and they fail (ansible-1.9.x), catch the ``ImportError`` exception and perform the equivalent imports for ansible-1.9.x. With possible translations (e.g. importing specific methods).
 
@@ -297,7 +297,7 @@ You may find the following tips useful:
 
 * When doing plugin development, it is very useful to have the ``warning()`` method during development, but it is also important to emit warnings for deadends (cases that you expect should never be triggered) or corner cases (e.g. cases where you expect misconfigurations).
 
-* It helps to look at other plugins in ansible-1.9.x and ansible-2.0 to understand how the API works and what modules, classes and methods are available.
+* It helps to look at other plugins in ansible-1.9.x and ansible-2.0 to understand how the API works and what modules, classes, and methods are available.
 
 
 Lookup plugins

docs/docsite/rst/porting_guide_2.3.rst

@@ -219,28 +219,6 @@ to connect to network devices, network modules now support the use of
 ``ProxyCommand``.
 
 To use ``ProxyCommand`` configure the proxy settings in the Ansible inventory
-file to specify the proxy host.
-
-.. code-block:: ini
-
-    [nxos]
-    nxos01
-    nxos02
-
-    [nxos:vars]
-    ansible_ssh_common_args='-o ProxyCommand="ssh -W %h:%p -q bastion01"'
-
-
-With the configuration above, simply build and run the playbook as normal with
-no additional changes necessary.  The network module will now connect to the
-network device by first connecting to the host specified in
-``ansible_ssh_common_args`` which is ``bastion01`` in the above example.
-
-
-.. notes: Using ``ProxyCommand`` with passwords via variables
-
-   It is a feature that SSH doesn't support providing passwords via environment variables.
-   This is done to prevent secrets from leaking out, for example in ``ps`` output.
-
-   We recommend using SSH Keys, and if needed and ssh-agent, rather than passwords, where ever possible.
+file to specify the proxy host via ``ansible_ssh_common_args``.
 
+For details on how to do this see the :ref:`network proxy guide <network_delegate_to_vs_ProxyCommand>`.

docs/docsite/rst/porting_guide_2.4.rst

@@ -0,0 +1,224 @@
+.. _porting_2.4_guide:
+
+*************************
+Ansible 2.4 Porting Guide
+*************************
+
+This section discusses the behavioral changes between Ansible 2.3 and Ansible 2.4.
+
+It is intended to assist in updating your playbooks, plugins and other parts of your Ansible infrastructure so they will work with this version of Ansible.
+
+
+We suggest you read this page along with `Ansible Changelog <https://github.com/ansible/ansible/blob/stable-2.4/CHANGELOG.md#2.4>`_ to understand what updates you may need to make.
+
+This document is part of a collection on porting. The complete list of porting guides can be found at :ref:`porting guides <porting_guides>`.
+
+.. contents:: Topics
+
+Python version
+==============
+
+Ansible will not support Python 2.4 or 2.5 on the target hosts anymore. Going forward, Python 2.6+ will be required on targets, as already is the case on the controller.
+
+
+Inventory
+=========
+
+Inventory has been refactored to be implemented via plugins and now allows for multiple sources. This change is mostly transparent to users.
+
+One exception is the ``inventory_dir``, which is now a host variable; previously it could only have one value so it was set globally.
+This means you can no longer use it early in plays to determine ``hosts:`` or similar keywords.
+This also changes the behaviour of ``add_hosts`` and the implicit localhost; 
+because they no longer automatically inherit the global value, they default to ``None``. See the module documentation for more information.
+
+The ``inventory_file`` remains unchanged, as it was always host specific.
+
+A bug was fixed with the inventory path/directory, which was defaulting to the current working directory. This caused ``group_vars`` and ``host_vars`` to be picked up from the current working directory instead of just adjacent to the playbook or inventory directory when a host list (comma separated host names) was provided as inventory.
+
+Initial playbook relative group_vars and host_vars
+--------------------------------------------------
+
+In Ansible versions prior to 2.4, the inventory system would maintain the context of the initial playbook that was executed. This allowed successively included playbooks from other directories to inherit group_vars and host_vars placed relative to the top level playbook file.
+
+Due to some behavioral inconsistencies, this functionality will not be included in the new
+inventory system starting with Ansible version 2.4.
+
+Similar functionality can still be achieved by using vars_files, include_vars, or group_vars and host_vars placed relative to the inventory file.
+
+Deprecated
+==========
+
+Specifying Inventory sources
+-----------------------------
+
+Use of ``--inventory-file`` on the command line is now deprecated. Use ``--inventory`` or ``-i``.
+The associated ini configuration key, ``hostfile``, and environment variable, :envvar:`ANSIBLE_HOSTS`,
+are also deprecated.  Replace them with the configuration key ``inventory`` and environment variable :envvar:`ANSIBLE_INVENTORY`.
+
+Use of multiple tags
+--------------------
+
+Specifying ``--tags`` (or ``--skip-tags``) multiple times on the command line currently leads to the last one overriding all the previous ones. This behavior is deprecated. In the future, if you specify --tags multiple times the tags will be merged together. From now on, using ``--tags`` multiple times on one command line will emit a deprecation warning. Setting the ``merge_multiple_cli_tags`` option to True in the ``ansible.cfg`` file will enable the new behavior.
+
+In 2.4, the default has change to merge the tags. You can enable the old overwriting behavior via the config option.
+
+In 2.5, multiple ``--tags`` options will be merged with no way to go back to the old behavior.
+
+
+Other caveats
+-------------
+
+No major changes in this version.
+
+Modules
+=======
+
+Major changes in popular modules are detailed here
+
+* The :ref:`win_shell <win_shell>` and :ref:`win_command <win_command>` modules now properly preserve quoted arguments in the command-line. Tasks that attempted to work around the issue by adding extra quotes/escaping may need to be reworked to remove the superfluous escaping. See `Issue 23019 <https://github.com/ansible/ansible/issues/23019>`_ for additional detail.
+
+Modules removed
+---------------
+
+The following modules no longer exist:
+
+* None
+
+Deprecation notices
+-------------------
+
+The following modules will be removed in Ansible 2.8. Please update update your playbooks accordingly.
+
+* :ref:`azure <azure>`, use :ref:`azure_rm_virtualmachine <azure_rm_virtualmachine>`, which uses the new Resource Manager SDK.
+* :ref:`win_msi <win_msi>`, use :ref:`win_package <win_package>` instead
+
+Noteworthy module changes
+-------------------------
+
+* The :ref:`win_get_url <win_get_url>`  module has the dictionary ``win_get_url`` in its results deprecated, its content is now also available directly in the resulting output, like other modules. This dictionary will be removed in Ansible 2.8.
+* The :ref:`win_unzip <win_unzip>` module no longer includes the dictionary ``win_unzip`` in its results; the contents are now included directly in the resulting output, like other modules.
+* The :ref:`win_package <win_package>` module return values ``exit_code`` and ``restart_required`` have been deprecated in favour of ``rc`` and ``reboot_required`` respectively. The deprecated return values will be removed in Ansible 2.6.
+
+
+Plugins
+=======
+
+A new way to configure and document plugins has been introduced.  This does not require changes to existing setups but developers should start adapting to the new infrastructure now. More details will be available in the developer documentation for each plugin type.
+
+Vars plugin changes
+-------------------
+
+There have been many changes to the implementation of vars plugins, but both users and developers should not need to change anything to keep current setups working. Developers should consider changing their plugins take advantage of new features.
+
+The most notable difference to users is that vars plugins now get invoked on demand instead of at inventory build time.  This should make them more efficient for large inventories, especially when using a subset of the hosts.
+
+
+.. note::
+  - This also creates a difference with group/host_vars when using them adjacent to playbooks. Before, the 'first' playbook loaded determined the variables; now the 'current' playbook does. We are looking to fix this soon, since 'all playbooks' in the path should be considered for variable loading.
+  - In 2.4.1 we added a toggle to allow you to control this behaviour, 'top' will be the pre 2.4, 'bottom' will use the current playbook hosting the task and 'all' will use them all from top to bottom.
+
+
+Inventory plugins
+-----------------
+
+Developers should start migrating from hardcoded inventory with dynamic inventory scripts to the new Inventory Plugins. The scripts will still work via the ``script`` inventory plugin but Ansible development efforts will now concentrate on writing plugins rather than enhancing existing scripts.
+
+Both users and developers should look into the new plugins because they are intended to alleviate the need for many of the hacks and workarounds found in the dynamic inventory scripts.
+
+Callback plugins
+----------------
+
+Users:
+
+* Callbacks are now using the new configuration system.  Users should not need to change anything as the old system still works,
+  but you might see a deprecation notice if any callbacks used are not inheriting from the built in classes. Developers need to update them as stated below.
+
+Developers:
+
+* If your callback does not inherit from ``CallbackBase`` (directly or indirectly via another callback), it will still work, but issue a deprecation notice.
+  To avoid this and ensure it works in the future change it to inherit from ``callbackBase`` so it has the new options handling methods and properties.
+  You can also implement the new options handling methods and properties but that won't automatically inherit changes added in the future.  You can look at ``CallbackBase`` itself and/or ``AnsiblePlugin`` for details.
+* Any callbacks inheriting from other callbacks might need to also be updated to contain the same documented options
+  as the parent or the options won't be available.  This is noted in the developer guide.
+
+Template lookup plugin: Escaping Strings
+----------------------------------------
+
+Prior to Ansible 2.4, backslashes in strings passed to the template lookup plugin would be escaped
+automatically. In 2.4, users are responsible for escaping backslashes themselves. This change
+brings the template lookup plugin inline with the template module so that the same backslash
+escaping rules apply to both.
+
+If you have a template lookup like this::
+
+    - debug:
+        msg: '{{ lookup("template", "template.j2") }}'
+
+**OLD** In Ansible 2.3 (and earlier) :file:`template.j2` would look like this:
+
+.. code-block:: jinja
+
+    {{ "name surname" | regex_replace("^[^\s]+\s+(.*)", "\1") }}
+
+**NEW** In Ansible 2.4 it should be changed to look like this:
+
+.. code-block:: jinja
+
+    {{ "name surname" | regex_replace("^[^\\s]+\\s+(.*)", "\\1") }}
+
+Tests
+=====
+
+Tests succeeded/failed
+-----------------------
+
+Prior to Ansible version 2.4, a task return code of ``rc`` would override a return code of ``failed``. In version 2.4,  both ``rc`` and ``failed`` are used to calculate the state of the task. Because of this, test plugins ``succeeded``/``failed``` have also been changed. This means that overriding a task failure with ``failed_when: no`` will result in ``succeeded``/``failed`` returning ``True``/``False``. For example:
+
+    - command: /bin/false
+      register: result
+      failed_when: no
+
+    - debug:
+        msg: 'This is printed on 2.3'
+      when: result|failed
+
+    - debug:
+        msg: 'This is printed on 2.4'
+      when: result|succeeded
+
+    - debug:
+        msg: 'This is always printed'
+      when: result.rc != 0
+
+As we can see from the example above, in Ansible 2.3 ``succeeded``/``failed`` only checked the value of ``rc``.
+
+Networking
+==========
+
+There have been a number of changes to how Networking Modules operate.
+
+Playbooks should still use ``connection: local``.
+
+Persistent Connection
+---------------------
+
+The configuration variables ``connection_retries`` and ``connect_interval`` which were added in Ansible 2.3 are now deprecated. For Ansible 2.4 and later use ``connection_retry_timeout``.
+
+To control timeouts use ``command_timeout`` rather than the previous top level ``timeout`` variable under ``[default]``
+
+See :ref:`Ansible Network debug guide <network_debug_troubleshooting>` for more information.
+
+
+Configuration
+=============
+
+
+The configuration system has had some major changes. Users should be unaffected except for the following:
+
+* All relative paths defined are relative to the `ansible.cfg` file itself. Previously they varied by setting. The new behavior should be more predictable.
+* A new macro ``{{CWD}}`` is available for paths, which will make paths relative to the 'current working directory',
+  this is unsafe but some users really want to rely on this behaviour.
+
+Developers that were working directly with the previous API should revisit their usage as some methods (for example, ``get_config``) were  kept for backwards compatibility but will warn users that the function has been deprecated.
+
+The new configuration has been designed to minimize the need for code changes in core for new plugins.  The plugins just need to document their settings and the configuration system will use the documentation to provide what they need. This is still a work in progress; currently only 'callback' and 'connection' plugins support this.  More  details will be added to the specific plugin developer guides.

docs/docsite/rst/release_and_maintenance.rst

@@ -4,7 +4,7 @@ Release and maintenance
 .. contents:: Topics
    :local:
 
-.. _schedule:
+.. _release_cycle:
 
 Release cycle
 `````````````
@@ -13,15 +13,18 @@ Ansible is developed and released on a flexible 4 months release cycle.
 This cycle can be extended in order to allow for larger changes to be properly
 implemented and tested before a new release is made available.
 
-Ansible supports the two most recent major stable releases.
-For more information, read about the
-`development and stable version maintenance workflow`_.
+Ansible has a graduated support structure that extends to three major releases.
+For more information, read about the `development and stable version maintenance workflow`_ or see
+the chart in :ref:`schedule` for the degrees to which current releases are supported.
+
+.. note:: Support for three major releases began with Ansible-2.4. Ansible-2.3 and older versions
+    are only supported for two releases.
 
 If you are using a release of Ansible that is no longer supported, we strongly
 encourage you to upgrade as soon as possible in order to benefit from the
 latest features and security fixes.
 
-Older unsupported versions of Ansible can contain unfixed security
+Older, unsupported versions of Ansible can contain unfixed security
 vulnerabilities (*CVE*).
 
 You can refer to the `porting guide`_ for tips on updating your Ansible
@@ -29,28 +32,33 @@ playbooks to run on newer versions.
 
 .. _porting guide: https://docs.ansible.com/ansible/porting_guide_2.0.html
 
+.. _release_schedule:
+
 Release status
 ``````````````
 
-+-----------------+----------------------------+----------------------------------------+
-| Ansible release | Latest version             | Status                                 |
-+=================+============================+========================================+
-| devel           | `2.4`_ (unreleased, trunk) | In development                         |
-+-----------------+----------------------------+----------------------------------------+
-| 2.3             | `2.3.2`_ (2017-08-08)      | Supported (bug **and** security fixes) |
-+-----------------+----------------------------+----------------------------------------+
-| 2.2             | `2.2.3`_ (2017-05-09)      | Supported (**only** security fixes)    |
-+-----------------+----------------------------+----------------------------------------+
-| 2.1             | `2.1.6`_ (2017-06-01)      | Unsupported (end of life)              |
-+-----------------+----------------------------+----------------------------------------+
-| 2.0             | `2.0.2`_ (2016-04-19)      | Unsupported (end of life)              |
-+-----------------+----------------------------+----------------------------------------+
-| 1.9             | `1.9.6`_ (2016-04-15)      | Unsupported (end of life)              |
-+-----------------+----------------------------+----------------------------------------+
-| <1.9            | n/a                        | Unsupported (end of life)              |
-+-----------------+----------------------------+----------------------------------------+
+===============   ==========================   =================================================
+Ansible Release   Latest Version               Status
+===============   ==========================   =================================================
+devel             `2.6` (unreleased, trunk)    In development
+2.5               `2.5.5`_ (2018-06-14)        Supported (security **and** general bug fixes)
+2.4               `2.4.6`_ (2018-07-05)        Supported (security **and** critical bug fixes)
+2.3               `2.3.2`_ (2017-08-08)        Unsupported (end of life)
+2.2               `2.2.3`_ (2017-05-09)        Unsupported (end of life)
+2.1               `2.1.6`_ (2017-06-01)        Unsupported (end of life)
+2.0               `2.0.2`_ (2016-04-19)        Unsupported (end of life)
+1.9               `1.9.6`_ (2016-04-15)        Unsupported (end of life)
+<1.9              n/a                          Unsupported (end of life)
+===============   ==========================   =================================================
 
-.. _2.4: https://github.com/ansible/ansible/blob/devel/CHANGELOG.md
+.. note:: Starting with Ansible-2.4, support lasts for 3 releases.  Thus Ansible-2.4 will receive
+    security and general bug fixes when it is first released, security and critical bug fixes when
+    2.5 is released, and **only** security fixes once 2.6 is released.
+
+.. Comment: devel used to point here but we're currently revamping our changelog process and have no
+   link to a static changelog for devel _2.6: https://github.com/ansible/ansible/blob/devel/CHANGELOG.md
+.. _2.5.5: https://github.com/ansible/ansible/blob/stable-2.5/changelogs/CHANGELOG-v2.5.rst
+.. _2.4.6: https://github.com/ansible/ansible/blob/stable-2.4/CHANGELOG.md
 .. _2.3.2: https://github.com/ansible/ansible/blob/stable-2.3/CHANGELOG.md
 .. _2.2.3: https://github.com/ansible/ansible/blob/stable-2.2/CHANGELOG.md
 .. _2.1.6: https://github.com/ansible/ansible/blob/stable-2.1/CHANGELOG.md
@@ -60,18 +68,23 @@ Release status
 .. _support_life:
 .. _methods:
 
+
 Development and stable version maintenance workflow
 ```````````````````````````````````````````````````
 
 The Ansible community develops and maintains Ansible on GitHub_.
 
-New modules, plugins, features and bugfixes will always be integrated in what
-will become the next major version of Ansible.
-This work is tracked on the ``devel`` git branch.
+New modules, plugins, features, and bugfixes will always be integrated in what will become the next
+major version of Ansible.  This work is tracked on the ``devel`` git branch.
 
-Ansible provides bugfixes and security improvements for the most recent major
-release while the previous major release will only receive security patches.
-This work is tracked on the ``stable-<version>`` git branches.
+Ansible provides bugfixes and security improvements for the most recent major release. The previous
+major release will only receive fixes for security issues and critical bugs. Ansible only applies
+security fixes to releases which are two releases old. This work is tracked on the
+``stable-<version>`` git branches.
+
+.. note:: Support for three major releases began with Ansible-2.4. Ansible-2.3 and older versions
+    are only supported for two releases with the first stage including both security and general bug
+    fixes while the second stage includes security and critical bug fixes.
 
 The fixes that land in supported stable branches will eventually be released
 as a new version when necessary.
@@ -85,6 +98,7 @@ releases of Ansible, there can sometimes be exceptions for critical issues.
 .. _GitHub: https://github.com/ansible/ansible
 .. _changelog: https://github.com/ansible/ansible/blob/devel/CHANGELOG.md
 
+
 Release candidates
 ~~~~~~~~~~~~~~~~~~
 
@@ -108,7 +122,7 @@ More release candidates can be tagged as required, so long as there are
 bugs that the Ansible core maintainers consider should be fixed before the
 final release.
 
-.. _freezing:
+.. _release_freezing:
 
 Feature freeze
 ~~~~~~~~~~~~~~

docs/docsite/rst/roadmap/ROADMAP_2_1.rst

@@ -95,11 +95,11 @@ Expand module diff support (already in progress in devel)
 
 Other
 -----
-Things being kicking down the road that we said we’d do
+Things being kicking down the road that we said we'd do
 
 - NOT remerging core with ansible/ansible this release cycle
 
 Community
 ---------
-- Define the process/ETA for reviewing PR’s from community
+- Define the process/ETA for reviewing PR's from community
 - Publish better docs and how-tos for submitting code/features/fixes

docs/docsite/rst/roadmap/ROADMAP_2_2.rst

@@ -19,7 +19,7 @@ Extras split from Core
 ----------------------
 Lead by Jason M and Jimi-c (Targeting 2.2, could move into 2.3).
 
-Targeted towards the 2.2 release or shortly after, we are planning on splitting Extras out of the “Ansible Core” project.  That means that modules that are shipped with Ansible by default are **only** the modules in ansibl-modules-core.  Ansible extras will become a separate project, managed by the community standard.  Over the next few months we’re going to have a lot of work to do on getting all of the modules in the right places for this to work.
+Targeted towards the 2.2 release or shortly after, we are planning on splitting Extras out of the "Ansible Core" project.  That means that modules that are shipped with Ansible by default are **only** the modules in ansibl-modules-core.  Ansible extras will become a separate project, managed by the community standard.  Over the next few months we're going to have a lot of work to do on getting all of the modules in the right places for this to work.
 
 - Create proposal (Jason or Jimi)
 - Review modules for correct location (extras v core)
@@ -40,7 +40,7 @@ AWS
 ---
 Lead by Ryan Brown
 
-- Pagination for all AWS modules (generic pagination exists, but isn’t used everywhere) (bumped to 2.3)
+- Pagination for all AWS modules (generic pagination exists, but isn't used everywhere) (bumped to 2.3)
 - Refactoring ec2.py to be more digestible (bumped to 2.3)
 - Fix inconsistencies with different authentication methods (STS, environment creds, ~/.aws/credentials) (done)
 - AWS Lambda modules (lambda_execute done, others pending)
@@ -85,7 +85,7 @@ Lead by Matt D
 
 - Feature parity
 
-  - PS module API (mirror Python module API where appropriate). Note: We don’t necessarily like the current python module API (AnsibleModule is a huge class with many unrelated utility functions.  Maybe we should redesign both at the same time?) (bumped to 2.3+ due to "moving target" uncertainty)
+  - PS module API (mirror Python module API where appropriate). Note: We don't necessarily like the current python module API (AnsibleModule is a huge class with many unrelated utility functions.  Maybe we should redesign both at the same time?) (bumped to 2.3+ due to "moving target" uncertainty)
   - Environment keyword support (done)
   - win_shell/win_command (done)
   - Async support (done)
@@ -117,7 +117,7 @@ Lead by Nate C, Peter S
 
 Role revamp
 -----------
-- Implement ‘role revamp’ proposal to give users more control on role/task execution (Brian)
+- Implement 'role revamp' proposal to give users more control on role/task execution (Brian)
 
   - **https://github.com/ansible/proposals/blob/master/roles_revamp.md**
 
@@ -125,13 +125,13 @@ Vault
 -----
 Lead by Jtanner, Adrian
 
-- *Extend ‘transparent vault file usage’ to other action plugins other than 'copy'(https://github.com/ansible/ansible/issues/7298)*
+- *Extend 'transparent vault file usage' to other action plugins other than 'copy'(https://github.com/ansible/ansible/issues/7298)*
   **done:** https://github.com/ansible/ansible/pull/16957
-- Add ‘per variable’ vault support (!vault YAML directive, existing PR already) https://github.com/ansible/ansible/issues/13287 https://github.com/ansible/ansible/issues/14721
+- Add 'per variable' vault support (!vault YAML directive, existing PR already) https://github.com/ansible/ansible/issues/13287 https://github.com/ansible/ansible/issues/14721
 - Add vault/unvault filters https://github.com/ansible/ansible/issues/12087 (deferred to 2.3)
 - Add vault support to lookups (likely deferred to 2.3 or until lookup plugins are revamped)
 - Allow for multiple vault secrets https://github.com/ansible/ansible/issues/13243
-- Config option to turn ‘unvaulting’ failures into warnings https://github.com/ansible/ansible/issues/13244
+- Config option to turn 'unvaulting' failures into warnings https://github.com/ansible/ansible/issues/13244
 
 Python3
 -------
@@ -139,7 +139,7 @@ Lead by Toshio
 
 A note here from Jason M: Getting to complete, tested Python 3 is both
 a critical task and one that has so much work and so many moving parts
-that we don’t expect this to be complete by the 2.2 release.  Toshio will
+that we don't expect this to be complete by the 2.2 release.  Toshio will
 lead this overall effort.
 
 - Motivation:
@@ -173,7 +173,7 @@ lead this overall effort.
     - Update: copy of the six library (v1.4.1 for python2.4 compat) and unicode helpers are here (ansible.module_utils._text.{to_bytes,to_text,to_native})
   - A few basic modules ported to python3
 
-    - Stat module best example module since it’s essential.
+    - Stat module best example module since it's essential.
     - Update:
 
       - A handful of modules like stat have been line-by-line ported.  They should work reliably with few python3-specific bugs.  All but three integration tests pass which means that most essential modules are working to some extent on Python3.
@@ -186,7 +186,7 @@ lead this overall effort.
     - lib/ansible/* and all modules now compile under Python-3.5
 
   - Side work to do:
-    - Figure out best ways to run unit-tests on modules.  Start unit-testing modules.  This is going to become important so we don’t regress python3 or python2.4 support in modules  (Going to largely punt on this for 2.2.  Matt Clay is working on building us a testing foundation for the first half of 2.2 development so we’ll re-evaluate towards the middle of the dev cycle).
+    - Figure out best ways to run unit-tests on modules.  Start unit-testing modules.  This is going to become important so we don't regress python3 or python2.4 support in modules  (Going to largely punt on this for 2.2.  Matt Clay is working on building us a testing foundation for the first half of 2.2 development so we'll re-evaluate towards the middle of the dev cycle).
     - More unit tests of module_utils
     - More integration tests.  Currently integration tests are the best way to test ansible modules so we have to rely on those.
 
@@ -202,7 +202,7 @@ Infrastructure Buildout and Changes
 -----------------------------------
 Lead by Matt Clay
 
-Another note from Jason M: A lot of this work is to ease the burden of CI, CI performance, increase our testing coverage and all of that sort of thing.  It’s not necessarily feature work, but it’s \*\*critical\*\* to growing our product and our ability to get community changes in more securely and quickly.
+Another note from Jason M: A lot of this work is to ease the burden of CI, CI performance, increase our testing coverage and all of that sort of thing.  It's not necessarily feature work, but it's \*\*critical\*\* to growing our product and our ability to get community changes in more securely and quickly.
 
 - **CI Performance**
   Reduce time spent waiting on CI for PRs. Combination of optimizing existing Travis setup and offloading work to other services. Will be impacted by available budget.

docs/docsite/rst/roadmap/ROADMAP_2_3.rst

@@ -46,7 +46,7 @@ Lead by nitzmahone
   - Become support **(done/experimental)**
   - Integrated kerberos ticket management (via ansible_user/ansible_password) **(done)**
   - Switch PS input encoding to BOM-less UTF8 **(done)**
-  - Server 2016 support/testing (now RTM’d) **(partial)**
+  - Server 2016 support/testing (now RTM'd) **(partial)**
   - Modularize Windows module_utils (allow N files) **(partial)**
   - Declarative argspec for PS / .NET **(bumped to 2.4)**
   - Kerberos encryption (via notting, pywinrm/requests_kerberos/pykerberos) **(in progress, available in pywinrm post 2.3 release)**
@@ -98,8 +98,8 @@ Python3
 
   - If users report bugs on python3, these should be fixed and will prioritize our work on porting other modules.
 
-- Still have to solve the python3-only and python2-only modules.  Thinking of doing this via metadata.  Will mean we have to use metadata at the module_common level.  Will also mean we don’t support py2-only or py3-only old style python modules.
-- Note: Most of the currently tested ansible features now run.  But there’s still a lot of code that’s untested.
+- Still have to solve the python3-only and python2-only modules.  Thinking of doing this via metadata.  Will mean we have to use metadata at the module_common level.  Will also mean we don't support py2-only or py3-only old style python modules.
+- Note: Most of the currently tested ansible features now run.  But there's still a lot of code that's untested.
 
 Testing and CI
 --------------
@@ -145,7 +145,7 @@ Amazon
 Lead by ryansb
 
 - Improve ec2.py integration tests **(partial, more to do in 2.4)**
-- ELB version 2 **(pushed - needs_revision [PR](https://github.com/ansible/ansible/pull/19491))**
+- ELB version 2 **(pushed - needs_revision)** `PR <https://github.com/ansible/ansible/pull/19491>`_
 - CloudFormation YAML, cross-stack reference, and roles support **(done)**
 - ECS module refactor **(done)**
 - AWS module unit testing w/ placebo (boto3 only) **(pushed 2.4)**
@@ -157,7 +157,7 @@ Plugin Loader
 
 ansible-ssh
 -----------
-- Add a ‘ansible-ssh’ convenience and debugging tool (will slip to 2.4)
+- Add a 'ansible-ssh' convenience and debugging tool (will slip to 2.4)
 - Tool to invoke an interactive ssh to a host with the same args/env/config that ansible would.
 - There are at least three external versions
 

docs/docsite/rst/roadmap/ROADMAP_2_4.rst

@@ -56,7 +56,7 @@ Inventory
 
 Facts
 -----
-- Configurable list of ‘fact modules’ for ``gather_facts`` **(done)**
+- Configurable list of 'fact modules' for ``gather_facts`` **(done)**
 - Fact gathering policy finer grained **(done)**
 - Make ``setup.py``/``facts`` more pluggable **(done)**
 - Improve testing of ``setup.py``/``facts.py`` **(done)**
@@ -104,8 +104,8 @@ Globalize Callbacks
 -------------------
 **(pushed out to future release)**
 - Make send_callback available to other code that cannot use it.
-- Would allow for ‘full formatting’ of output (see JSON callback)
-- Fixes static ‘include’ display problem
+- Would allow for 'full formatting' of output (see JSON callback)
+- Fixes static 'include' display problem
 
 Plugins
 -------
@@ -128,13 +128,13 @@ Runtime Check on Modules for Blacklisting
 
 Disambiguate Includes
 ---------------------
-- Create import_x for ‘static includes’ (import_task, import_play, import_role)
+- Create import_x for 'static includes' (import_task, import_playbook, import_role)
 
-  - Any directives are applied to the ‘imported’ tasks
+  - Any directives are applied to the 'imported' tasks
 
-- Create include_x for ‘dynamic includes’ (include_task, include_role)
+- Create include_x for 'dynamic includes' (include_task, include_role)
 
-  - Any directives apply to the ‘include’  itself
+  - Any directives apply to the 'include'  itself
 
 Windows
 -------

docs/docsite/rst/vault.rst

@@ -5,7 +5,7 @@ Ansible Vault
 
 New in Ansible 1.5, "Vault" is a feature of ansible that allows keeping sensitive data such as passwords or keys in encrypted files, rather than as plaintext in your playbooks or roles. These vault files can then be distributed or placed in source control.
 
-To enable this feature, a command line tool, :ref:`ansible-vault` is used to edit files, and a command line flag `--ask-vault-pass` or `--vault-password-file` is used. Alternately, you may specify the location of a password file or command Ansible to always prompt for the password in your ansible.cfg file. These options require no command line flag usage.
+To enable this feature, a command line tool - :ref:`ansible-vault` - is used to edit files, and a command line flag (:option:`--ask-vault-pass <ansible-playbook --ask-vault-pass>` or :option:`--vault-password-file <ansible-playbook --vault-password-file>`) is used. Alternately, you may specify the location of a password file or command Ansible to always prompt for the password in your ansible.cfg file. These options require no command line flag usage.
 
 For best practices advice, refer to :ref:`best_practices_for_variables_and_vaults`.
 
@@ -14,12 +14,12 @@ For best practices advice, refer to :ref:`best_practices_for_variables_and_vault
 What Can Be Encrypted With Vault
 ````````````````````````````````
 
-The vault feature can encrypt any structured data file used by Ansible.  This can include "group_vars/" or "host_vars/" inventory variables, variables loaded by "include_vars" or "vars_files", or variable files passed on the ansible-playbook command line with "-e @file.yml" or "-e @file.json".  Role variables and defaults are also included!
+The vault feature can encrypt any structured data file used by Ansible.  This can include "group_vars/" or "host_vars/" inventory variables, variables loaded by "include_vars" or "vars_files", or variable files passed on the ansible-playbook command line with ``-e @file.yml`` or ``-e @file.json``.  Role variables and defaults are also included.
 
-Ansible tasks, handlers, and so on are also data so these can be encrypted with vault as well. To hide the names of variables that you're using, you can encrypt the task files in their entirety. However, that might be a little too much and could annoy your coworkers :)
+Ansible tasks, handlers, and so on are also data so these can be encrypted with vault as well. To hide the names of variables that you're using, you can encrypt the task files in their entirety.
 
 The vault feature can also encrypt arbitrary files, even binary files.  If a vault-encrypted file is
-given as the :ref:`src <src>` argument to the :ref:`copy <copy>`, :ref:`template <template>`,
+given as the ``src`` argument to the :ref:`copy <copy>`, :ref:`template <template>`,
 :ref:`unarchive <unarchive>`, :ref:`script <script>` or :ref:`assemble <assemble>` modules, the file will be placed at the destination on the target host decrypted (assuming a valid vault password is supplied when running the play).
 
 As of version 2.3, Ansible also supports encrypting single values inside a YAML file, using the `!vault` tag to let YAML and Ansible know it uses special processing. This feature is covered in more details below.
@@ -48,7 +48,7 @@ The default cipher is AES (which is shared-secret based).
 Editing Encrypted Files
 ```````````````````````
 
-To edit an encrypted file in place, use the :ref:`ansible-vault edit` command.
+To edit an encrypted file in place, use the :ref:`ansible-vault edit <ansible_vault_edit>` command.
 This command will decrypt the file to a temporary file and allow you to edit
 the file, saving it back when done and removing the temporary file:
 
@@ -78,7 +78,7 @@ Encrypting Unencrypted Files
 ````````````````````````````
 
 If you have existing files that you wish to encrypt, use
-the :ref:`ansible-vault encrypt` command.  This command can operate on multiple files at once:
+the :ref:`ansible-vault encrypt <ansible_vault_encrypt>` command.  This command can operate on multiple files at once:
 
 .. code-block:: bash
 
@@ -91,8 +91,8 @@ Decrypting Encrypted Files
 ``````````````````````````
 
 If you have existing files that you no longer want to keep encrypted, you can permanently decrypt
-them by running the :ref:`ansible-vault decrypt` command.  This command will save them unencrypted
-to the disk, so be sure you do not want :ref:`ansible-vault edit` instead:
+them by running the :ref:`ansible-vault decrypt <ansible_vault_decrypt>` command.  This command will save them unencrypted
+to the disk, so be sure you do not want :ref:`ansible-vault edit <ansible_vault_edit>` instead:
 
 .. code-block:: bash
 
@@ -106,7 +106,7 @@ Viewing Encrypted Files
 
 *Available since Ansible 1.8*
 
-If you want to view the contents of an encrypted file without editing it, you can use the :ref:`ansible-vault view` command:
+If you want to view the contents of an encrypted file without editing it, you can use the :ref:`ansible-vault view <ansible_vault_view>` command:
 
 .. code-block:: bash
 
@@ -118,10 +118,11 @@ If you want to view the contents of an encrypted file without editing it, you ca
 Use encrypt_string to create encrypted variables to embed in yaml
 `````````````````````````````````````````````````````````````````
 
-The :ref:`ansible-vault encrypt_string` command will encrypt and format a provided string into a format
+The :ref:`ansible-vault encrypt_string <ansible_vault_encrypt_string>` command will encrypt and format a provided string into a format
 that can be included in :ref:`ansible-playbook` YAML files.
 
 To encrypt a string provided as a cli arg:
+
 .. code-block:: bash
 
     ansible-vault encrypt_string --vault-id a_password_file 'foobar' --name 'the_secret'
@@ -224,7 +225,7 @@ Providing Vault Passwords
 `````````````````````````
 
 Since Ansible 2.4, the recommended way to provide a vault password from the cli is
-to use the :option:`--vault-id` cli option.
+to use the :option:`--vault-id <ansible-playbook --vault-id>` cli option.
 
 For example, to use a password store in the text file :file:`/path/to/my/vault-password-file`:
 
@@ -244,7 +245,7 @@ To get the password from a vault password executable script :file:`my-vault-pass
 
     ansible-playbook --vault-id my-vault-password.py
 
-The value for :option:`--vault-id` can specify the type of vault id (prompt, a file path, etc)
+The value for :option:`--vault-id <ansible-playbook --vault-id>` can specify the type of vault id (prompt, a file path, etc)
 and a label for the vault id ('dev', 'prod', 'cloud', etc)
 
 For example, to use a password file :file:`dev-password` for the vault-id 'dev':
@@ -261,33 +262,26 @@ To prompt for the 'dev' vault id:
 
 *Prior to Ansible 2.4*
 
-To be prompted for a vault password, use the :option:`--ask-vault-pass` cli option:
+To be prompted for a vault password, use the :option:`--ask-vault-pass <ansible-playbook --vault-id>` cli option:
 
 .. code-block:: bash
 
     ansible-playbook --ask-vault-pass site.yml
 
-To specify a vault password in a text file 'dev-password', use the :option:`--vault-password-file` option:
+To specify a vault password in a text file 'dev-password', use the :option:`--vault-password-file <ansible-playbook --vault-password-file>` option:
 
 .. code-block:: bash
 
     ansible-playbook --vault-password-file dev-password site.yml
 
 There is a config option (:ref:`DEFAULT_VAULT_PASSWORD_FILE`) to specify a vault password file to use
-without requiring the :option:`--vault-password-file` cli option.
+without requiring the :option:`--vault-password-file <ansible-playbook --vault-password-file>` cli option.
 
-via config
-  :ref:`ANSIBLE_VAULT_PASSWORD_FILE`
-
-  :ref:`ANSIBLE_VAULT_IDENTITY_LIST`
-
-via env
-   TODO
 
 Multiple vault passwords
 ^^^^^^^^^^^^^^^^^^^^^^^^
 
-Since Ansible 2.4 and later support using multiple vault passwords, :option:`--vault-id` can
+Since Ansible 2.4 and later support using multiple vault passwords, :option:`--vault-id <ansible-playbook --vault-id>` can
 be provided multiple times.
 
 If multiple vault passwords are provided, by default Ansible will attempt to decrypt vault content
@@ -302,7 +296,7 @@ For example, to use a 'dev' password read from a file and to be prompted for the
 In the above case, the 'dev' password will be tried first, then the 'prod' password for cases
 where Ansible doesn't know which vault id is used to encrypt something.
 
-If the vault content was encrypted using a :option:`--vault-id` option, then the label of the
+If the vault content was encrypted using a :option:`--vault-id <ansible-vault --vault-id>` option, then the label of the
 vault id is stored with the vault content. When Ansible knows the right vault-id, it will try
 the matching vault id's secret first before trying the rest of the vault-ids.
 
@@ -317,17 +311,17 @@ use. For example, instead of requiring the cli option on every use, the (:ref:`D
 
     ansible-playbook --vault-id dev@dev-password --vault-id prod@prompt site.yml
 
-The :option:`--vault-id` can be used in lieu of the :option:`--vault-password-file` or :option:`--ask-vault-pass` options,
+The :option:`--vault-id <ansible-playbook --vault-id>` can be used in lieu of the :option:`--vault-password-file <ansible-playbook --vault-password-file>` or :option:`--ask-vault-pass <ansible-playbook --ask-vault-pass>` options,
 or it can be used in combination with them.
 
-When using :ref:`ansible-vault` command that encrypt content (:ref:`ansible-vault encrypt`, :ref:`ansible-vault encrypt_string`, etc)
+When using :ref:`ansible-vault` commands that encrypt content (:ref:`ansible-vault encrypt <ansible_vault_encrypt>`, :ref:`ansible-vault encrypt_string <ansible_vault_encrypt_string>`, etc)
 only one vault-id can be used.
 
 
 
 .. note::
     Prior to Ansible 2.4, only one vault password could be used in each Ansible run. The
-    :option:`--vault-id` option is not support prior to Ansible 2.4.
+    :option:`--vault-id <ansible-playbook --vault-id>` option is not support prior to Ansible 2.4.
 
 
 .. _speeding_up_vault:

docs/docsite/rst_common/ansible_ssh_changes_note.rst

@@ -1,3 +1,3 @@
 .. note::
 
-    Ansible 2.0 has deprecated the “ssh” from ``ansible_ssh_user``, ``ansible_ssh_host``, and ``ansible_ssh_port`` to become ``ansible_user``, ``ansible_host``, and ``ansible_port``. If you are using a version of Ansible prior to 2.0,  you should continue using the older style variables (``ansible_ssh_*``). These shorter variables are ignored, without warning, in older versions of Ansible. 
+    Ansible 2.0 has deprecated the "ssh" from ``ansible_ssh_user``, ``ansible_ssh_host``, and ``ansible_ssh_port`` to become ``ansible_user``, ``ansible_host``, and ``ansible_port``. If you are using a version of Ansible prior to 2.0,  you should continue using the older style variables (``ansible_ssh_*``). These shorter variables are ignored, without warning, in older versions of Ansible.

docs/templates/cli_rst.j2

@@ -0,0 +1,139 @@
+{% set name = cli_name -%}
+{% set name_slug = cli_name -%}
+
+.. _{{name}}:
+
+{% set name_len = name|length + 0-%}
+{{ '=' * name_len }}
+{{name}}
+{{ '=' * name_len }}
+
+
+:strong:`{{short_desc|default('')}}`
+
+
+.. contents::
+   :local:
+   :depth: 2
+
+
+.. program:: {{cli_name}}
+
+Synopsis
+========
+
+.. code-block:: bash
+
+   {{ usage|replace('%prog', cli_name) }}
+
+
+Description
+===========
+
+
+{{ long_desc|default('', True)  }}
+
+{% if options %}
+Common Options
+==============
+
+
+{% for option in options|sort(attribute='options') %}
+
+.. option:: {% for switch in option['options'] %}{{switch}}{% if option['arg'] %} <{{option['arg']}}>{% endif %}{% if not loop.last %}, {% endif %}{% endfor %}
+
+   {{ option['desc'] }}
+{% endfor %}
+{% endif %}
+
+{% if arguments %}
+ARGUMENTS
+=========
+
+.. program:: {{cli_name}}
+
+{% for arg in arguments %}
+.. option:: {{ arg }}
+
+   {{ (arguments[arg]|default(' '))}}
+
+{% endfor %}
+{% endif %}
+
+{% if actions %}
+Actions
+=======
+
+{% for action in actions %}
+
+.. program:: {{cli_name}} {{action}}
+.. _{{cli_name|replace('-','_')}}_{{action}}:
+
+{{ action}}
+{{ '-' * action|length}}
+
+{{ (actions[action]['desc']|default(' '))}}
+
+{% if actions[action]['options'] %}
+
+
+{% for option in actions[action]['options']|sort %}
+.. option:: {% for switch in option['options'] if switch in actions[action]['option_names'] %}{{switch}} {% if option['arg'] %} <{{option['arg']}}>{% endif %}{% if not loop.last %}, {% endif %}{% endfor %}
+
+   {{ (option['desc']) }}
+{% endfor %}
+{% endif %}
+
+{% endfor %}
+.. program:: {{cli_name}}
+{% endif %}
+
+Environment
+===========
+
+The following environment variables may be specified.
+
+{% if inventory %}
+:envvar:`ANSIBLE_INVENTORY`  -- Override the default ansible inventory file
+
+{% endif %}
+{% if library %}
+:envvar:`ANSIBLE_LIBRARY` -- Override the default ansible module library path
+
+{% endif %}
+:envvar:`ANSIBLE_CONFIG` -- Override the default ansible config file
+
+Many more are available for most options in ansible.cfg
+
+
+Files
+=====
+
+{% if inventory %}
+:file:`/etc/ansible/hosts` -- Default inventory file
+
+{% endif %}
+:file:`/etc/ansible/ansible.cfg` -- Config file, used if present
+
+:file:`~/.ansible.cfg` -- User config file, overrides the default config if present
+
+Author
+======
+
+Ansible was originally written by Michael DeHaan.
+
+See the `AUTHORS` file for a complete list of contributors.
+
+
+Copyright
+=========
+
+Copyright © 2017 Red Hat, Inc | Ansible.
+
+Ansible is released under the terms of the GPLv3 License.
+
+See also
+========
+
+{% for other in cli_bin_name_list|sort %}:manpage:`{{other}}(1)`,  {% endfor %}
+

docs/templates/config.rst.j2

@@ -6,6 +6,72 @@
 {{name}}
 {{ '=' * name_len }}
 
+Ansible supports a few ways of providing configuration variables, mainly through environment variables, command line switches and an ini file named ``ansible.cfg``.
+
+Starting at Ansible 2.4 the ``ansible-config`` utility allows users to see all the configuration settings available, their defaults, how to set them and
+where their current value comes from. See :doc:ansible-config for more information.
+
+.. _ansible_configuration_settings_locations:
+
+The configuration file
+======================
+
+Changes can be made and used in a configuration file which will be searched for in the following order:
+
+ * ``ANSIBLE_CONFIG`` (environment variable if set)
+ * ``ansible.cfg`` (in the current directory)
+ * ``~/.ansible.cfg`` (in the home directory)
+ * ``/etc/ansible/ansible.cfg``
+
+Ansible will process the above list and use the first file found, all others are ignored.
+
+.. note::
+
+   The configuration file is one variant of an INI format.
+   Both the hash sign (``#``) and semicolon (``;``) are allowed as
+   comment markers when the comment starts the line.
+   However, if the comment is inline with regular values,
+   only the semicolon is allowed to introduce the comment.
+   For instance::
+
+        # some basic default values...
+        inventory = /etc/ansible/hosts  ; This points to the file that lists your hosts
+
+
+.. _cfg_in_world_writable_dir:
+
+Avoiding security risks with ``ansible.cfg`` in the current directory
+---------------------------------------------------------------------
+
+
+If Ansible were to load :file:ansible.cfg from a world-writable current working
+directory, it would create a serious security risk. Another user could place
+their own config file there, designed to make Ansible run malicious code both
+locally and remotely, possibly with elevated privileges. For this reason,
+Ansible will not automatically load a config file from the current working
+directory if the directory is world-writable.
+
+If you depend on using Ansible with a config file in the current working
+directory, the best way to avoid this problem is to restrict access to your
+Ansible directories to particular user(s) and/or group(s). If your Ansible
+directories live on a filesystem which has to emulate Unix permissions, like
+Vagrant or Windows Subsystem for Linux (WSL), you may, at first, not know how
+you can fix this as ``chmod``, ``chown``, and ``chgrp`` might not work there.
+In most of those cases, the correct fix is to modify the mount options of the
+filesystem so the files and directories are readable and writable by the users
+and groups running Ansible but closed to others.  For more details on the
+correct settings, see:
+
+* for Vagrant, Jeremy Kendall's `blog post <http://jeremykendall.net/2013/08/09/vagrant-synced-folders-permissions/>`_ covers synced folder permissions. 
+* for WSL, the `WSL docs <https://docs.microsoft.com/en-us/windows/wsl/wsl-config#set-wsl-launch-settings>`_
+  and this `Microsoft blog post <https://blogs.msdn.microsoft.com/commandline/2018/01/12/chmod-chown-wsl-improvements/>`_ cover mount options.
+
+If you absolutely depend on having the config live in a world-writable current
+working directory, you can explicitly specify the config file via the
+:envvar:`ANSIBLE_CONFIG` environment variable. Please take
+appropriate steps to mitigate the security concerns above before doing so.
+
+
 Common Options
 ==============
 

docs/templates/list_of_CATEGORY_modules.rst.j2

@@ -9,7 +9,7 @@
 {% if category['_modules'] %}
 
 {% for module in category['_modules'] | sort %}
-  @{ module }@{% if module_info[module]['deprecated'] %} **(D)**{% endif%} - @{ module_info[module]['doc']['short_description'] }@ <@{ module }@_module>
+  @{ module }@{% if module_info[module]['deprecated'] %} **(D)**{% endif%} -- @{ module_info[module]['doc']['short_description'] }@ <@{ module }@_module>
 {% endfor %}
 {% endif %}
 
@@ -20,7 +20,7 @@
 .. toctree:: :maxdepth: 1
 
 {% for module in info['_modules'] | sort %}
-  @{ module }@{% if module_info[module]['deprecated'] %} **(D)**{% endif%} - @{ module_info[module]['doc']['short_description'] }@ <@{ module }@_module>
+  @{ module }@{% if module_info[module]['deprecated'] %} **(D)**{% endif%} -- @{ module_info[module]['doc']['short_description'] }@ <@{ module }@_module>
 {% endfor %}
 
 {% endfor %}

docs/templates/man.j2

@@ -20,8 +20,17 @@ SYNOPSIS
 
 DESCRIPTION
 -----------
-*{{name}}* {{ long_desc|default('', True)|wordwrap }}
+{{ long_desc|default('', True)|wordwrap }}
 
+{% if options %}
+COMMON OPTIONS
+--------------
+{% for option in options|sort(attribute='options') %}
+{% for switch in option['options'] %}*{{switch}}*{% if option['arg'] %} '{{option['arg']}}'{% endif %}{% if not loop.last %}, {% endif %}{% endfor %}::
+
+{{ option['desc'] }}
+{% endfor %}
+{% endif %}
 
 {% if arguments %}
 ARGUMENTS
@@ -38,22 +47,19 @@ ARGUMENTS
 {% if actions %}
 ACTIONS
 -------
-
 {% for action in actions %}
-{{ action }}
+    *{{ action }}*::: {{ (actions[action]['desc']|default(' '))|wordwrap}}
 
-{{ (actions[action]|default(' '))|wordwrap}}
+{% if actions[action]['options'] %}
+{% for option in actions[action]['options']|sort %}
+{% for switch in option['options'] if switch in actions[action]['option_names'] %}*{{switch}}*{% if option['arg'] %} '{{option['arg']}}'{% endif %}{% if not loop.last %}, {% endif %}{% endfor %}::
 
+        {{ (option['desc']) }}
 {% endfor %}
 {% endif %}
-OPTIONS
--------
-
-{% for option in options|sort(attribute='options') %}
-{% for switch in option['options'] %}*{{switch}}* {% if option['arg'] %}'{{option['arg']}}'{% endif %}{% if not loop.last %}, {% endif %}{% endfor %}::
-
-{{ option['desc'] }}
 {% endfor %}
+{% endif %}
+
 
 {% if inventory %}
 INVENTORY
@@ -70,17 +76,18 @@ ENVIRONMENT
 The following environment variables may be specified.
 
 {% if inventory %}
-ANSIBLE_INVENTORY  -- Override the default ansible inventory file
+ANSIBLE_INVENTORY  -- Override the default ansible inventory sources
 
 {% endif %}
 {% if library %}
 ANSIBLE_LIBRARY -- Override the default ansible module library path
 
 {% endif %}
-ANSIBLE_CONFIG -- Override the default ansible config file
+ANSIBLE_CONFIG -- Specify override location for the ansible config file
 
 Many more are available for most options in ansible.cfg
 
+For a full list check https://docs.ansible.com/. or use the `ansible-config` command.
 
 FILES
 -----
@@ -93,6 +100,9 @@ FILES
 
 ~/.ansible.cfg -- User config file, overrides the default config if present
 
+./ansible.cfg -- Local config file (in current working direcotry) assumed to be 'project specific' and overrides the rest if present.
+
+As mentioned above, the ANSIBLE_CONFIG environment variable will override all others.
 
 AUTHOR
 ------
@@ -104,14 +114,14 @@ See the AUTHORS file for a complete list of contributors.
 COPYRIGHT
 ---------
 
-Copyright © 2017 Red Hat, Inc | Ansible.
-Ansible is released under the terms of the GPLv3 License.
+Copyright © 2018 Red Hat, Inc | Ansible.
+Ansible is released under the terms of the GPLv3 license.
 
 
 SEE ALSO
 --------
 
- {% for other in cli_list|sort %}{% if other != cli %}*ansible{% if other != 'adhoc' %}-{{other}}{% endif %}*(1){% if not loop.last %}, {% endif %}{% endif %}{% endfor %}
+{% for other in cli_list|sort %}{% if other != cli %}*ansible{% if other != 'adhoc' %}-{{other}}{% endif %}*(1){% if not loop.last %}, {% endif %}{% endif %}{% endfor %}
 
 Extensive documentation is available in the documentation site:
 <http://docs.ansible.com>.

docs/templates/playbooks_keywords.rst.j2

@@ -1,11 +1,16 @@
-Directives Glossary
-===================
+Playbook Keywords
+=================
 
-Here we list the common playbook objects and their directives.
-Note that not all directives affect the object itself and might just be there to be inherited by other contained objects.
-Aliases for the directives are not reflected here, nor are mutable ones, for example `action` in task can be substituted by the name of any module plugin.
+These are the keywords available on common playbook objects.
+
+.. note:: Please note:
+
+    * Aliases for the directives are not reflected here, nor are mutable one. For example,
+      :term:`action` in task can be substituted by the name of any Ansible module.
+    * The keywords do not have ``version_added`` information at this time
+    * Some keywords set defaults for the objects inside of them rather than for the objects
+      themselves
 
-Be aware that this reflects the 'current development branch' and that the keywords do not have 'version_added' information.
 
 .. contents::
    :local:
@@ -15,8 +20,11 @@ Be aware that this reflects the 'current development branch' and that the keywor
 
 {{ name }}
 {{ '-' * name|length }}
+.. glossary::
+
 {% for attribute in oblist[name]|sort %}
-  - **{{ attribute }}:** {{ oblist[name][attribute] }}
-{% endfor %}
+    {{ attribute }}
+        {{ oblist[name][attribute] |indent(8) }}
 
 {% endfor %}
+{% endfor %}

docs/templates/plugin.rst.j2

@@ -194,7 +194,7 @@ Common return values are documented here :doc:`common_return_values`, the follow
     <th class="head">type</th>
     <th class="head">sample</th>
     </tr>
-{% for entry in returndocs %}
+{% for entry, unusedvalue in returndocs|dictsort %}
 
     <tr>
     <td>@{ entry }@</td>

examples/ansible.cfg

@@ -297,10 +297,6 @@
 # only update this setting if you know how this works, otherwise it can break module execution
 #network_group_modules=['eos', 'nxos', 'ios', 'iosxr', 'junos', 'vyos']
 
-# This keeps facts from polluting the main namespace as variables.
-# Setting to True keeps them under the ansible_facts namespace, the default is False
-#restrict_facts_namespace: True
-
 # When enabled, this option allows lookups (via variables like {{lookup('foo')}} or when used as
 # a loop with `with_foo`) to return data that is not marked "unsafe". This means the data may contain
 # jinja2 templating language which will be run through the templating engine.
@@ -315,7 +311,7 @@
 #enable_plugins = host_list, virtualbox, yaml, constructed
 
 # ignore these extensions when parsing a directory as inventory source
-#ignore_extensions = '.pyc', '.pyo', '.swp', '.bak', '~', '.rpm', '.md', '.txt', '~', '.orig', '.ini', '.cfg', '.retry'
+#ignore_extensions = .pyc, .pyo, .swp, .bak, ~, .rpm, .md, .txt, ~, .orig, .ini, .cfg, .retry
 
 # ignore files matching these patterns when parsing a directory as inventory source
 #ignore_patterns=

examples/scripts/ConfigureRemotingForAnsible.ps1

@@ -52,7 +52,8 @@ Param (
     [switch]$SkipNetworkProfileCheck,
     $CreateSelfSignedCert = $true,
     [switch]$ForceNewSSLCert,
-    [switch]$EnableCredSSP
+    [switch]$EnableCredSSP,
+    [switch]$GlobalHttpFirewallAccess
 )
 
 Function Write-Log
@@ -71,7 +72,7 @@ Function Write-VerboseLog
 Function Write-HostLog
 {
     $Message = $args[0]
-    Write-Host $Message
+    Write-Output $Message
     Write-Log $Message
 }
 
@@ -121,6 +122,60 @@ Function New-LegacySelfSignedCert
     return $parsed_cert.Thumbprint
 }
 
+Function Enable-GlobalHttpFirewallAccess
+{
+    Write-Verbose "Forcing global HTTP firewall access"
+    # this is a fairly naive implementation; could be more sophisticated about rule matching/collapsing
+    $fw = New-Object -ComObject HNetCfg.FWPolicy2
+
+    # try to find/enable the default rule first
+    $add_rule = $false
+    $matching_rules = $fw.Rules | ? { $_.Name -eq "Windows Remote Management (HTTP-In)" }
+    $rule = $null
+    If ($matching_rules) {
+        If ($matching_rules -isnot [Array]) {
+            Write-Verbose "Editing existing single HTTP firewall rule"
+            $rule = $matching_rules
+        }
+        Else {
+            # try to find one with the All or Public profile first
+            Write-Verbose "Found multiple existing HTTP firewall rules..."
+            $rule = $matching_rules | % { $_.Profiles -band 4 }[0]
+
+            If (-not $rule -or $rule -is [Array]) {
+                Write-Verbose "Editing an arbitrary single HTTP firewall rule (multiple existed)"
+                # oh well, just pick the first one
+                $rule = $matching_rules[0]
+            }
+        }
+    }
+
+    If (-not $rule) {
+        Write-Verbose "Creating a new HTTP firewall rule"
+        $rule = New-Object -ComObject HNetCfg.FWRule
+        $rule.Name = "Windows Remote Management (HTTP-In)"
+        $rule.Description = "Inbound rule for Windows Remote Management via WS-Management. [TCP 5985]"
+        $add_rule = $true
+    }
+
+    $rule.Profiles = 0x7FFFFFFF
+    $rule.Protocol = 6
+    $rule.LocalPorts = 5985
+    $rule.RemotePorts = "*"
+    $rule.LocalAddresses = "*"
+    $rule.RemoteAddresses = "*"
+    $rule.Enabled = $true
+    $rule.Direction = 1
+    $rule.Action = 1
+    $rule.Grouping = "Windows Remote Management"
+
+    If ($add_rule) {
+        $fw.Rules.Add($rule)
+    }
+
+    Write-Verbose "HTTP firewall rule $($rule.Name) updated"
+}
+
 # Setup error handling.
 Trap
 {
@@ -139,8 +194,8 @@ $adminRole=[System.Security.Principal.WindowsBuiltInRole]::Administrator
 # Check to see if we are currently running "as Administrator"
 if (-Not $myWindowsPrincipal.IsInRole($adminRole))
 {
-    Write-Host "ERROR: You need elevated Administrator privileges in order to run this script."
-    Write-Host "       Start Windows PowerShell by using the Run as Administrator option."
+    Write-Output "ERROR: You need elevated Administrator privileges in order to run this script."
+    Write-Output "       Start Windows PowerShell by using the Run as Administrator option."
     Exit 2
 }
 
@@ -277,6 +332,10 @@ If ($EnableCredSSP)
     }
 }
 
+If ($GlobalHttpFirewallAccess) {
+    Enable-GlobalHttpFirewallAccess
+}
+
 # Configure firewall to allow WinRM HTTPS connections.
 $fwtest1 = netsh advfirewall firewall show rule name="Allow WinRM HTTPS"
 $fwtest2 = netsh advfirewall firewall show rule name="Allow WinRM HTTPS" profile=any

examples/scripts/uptime.py

@@ -3,7 +3,7 @@
 from collections import namedtuple
 
 from ansible.executor.task_queue_manager import TaskQueueManager
-from ansible.inventory import Inventory
+from ansible.inventory.manager import InventoryManager
 from ansible.parsing.dataloader import DataLoader
 from ansible.playbook.play import Play
 from ansible.plugins.callback import CallbackBase
@@ -33,21 +33,21 @@ def main():
     host_list = ['localhost', 'www.example.com', 'www.google.com']
     Options = namedtuple('Options', ['connection', 'module_path', 'forks', 'remote_user',
                                      'private_key_file', 'ssh_common_args', 'ssh_extra_args', 'sftp_extra_args',
-                                     'scp_extra_args', 'become', 'become_method', 'become_user', 'verbosity', 'check'])
+                                     'scp_extra_args', 'become', 'become_method', 'become_user', 'verbosity', 'check',
+                                     'diff'])
 
     # initialize needed objects
-    variable_manager = VariableManager()
     loader = DataLoader()
     options = Options(connection='smart', module_path='/usr/share/ansible', forks=100,
                       remote_user=None, private_key_file=None, ssh_common_args=None, ssh_extra_args=None,
                       sftp_extra_args=None, scp_extra_args=None, become=None, become_method=None,
-                      become_user=None, verbosity=None, check=False)
+                      become_user=None, verbosity=None, check=False, diff=False)
 
     passwords = dict()
 
     # create inventory and pass to var manager
-    inventory = Inventory(loader=loader, variable_manager=variable_manager, host_list=host_list)
-    variable_manager.set_inventory(inventory)
+    inventory = InventoryManager(loader=loader, sources=','.join(host_list))
+    variable_manager = VariableManager(loader=loader, inventory=inventory)
 
     # create play with tasks
     play_source = dict(