Fix bug with include-level vars and sudo_user.

Fixes apt_repository always reporting file uri repos as changed

Allow virtualenv_command argument of the pip module to be a pathname

Fixes #2991: Service module pattern argument ignored.

Fetch destination path can now be overriden.

Make pkgng and with_items result in a single module call.

Fix pip module documentation (YAML quoting)

add basename and dirname to the core jinja2 filters

Ensure the tmp_path is sufficiently open.

pip module -- sudo_user permission problem fix

Fixes #2924: User creation always reports 'changed'

ignore unicode errors in stdout

OpenStack Identity (keystone) user module

OpenStack Modules

new airbrake_deployment module

Python

Plug-ins loaded from top-level plug-in directory

Make debug module always verbose in playbooks

Created a new flag 'verbose_always' handled by
on_ok callback, similar to the 'verbose_override'
flag used by the setup module.

PluginLoader._get_paths, as of 391fb98e, was only finding plug-ins that
were in a subdirectory of one of the basedirs (i.e. in a category
directory).  For example, action_plugins/foo.py would never be loaded,
but action_plugins/bar/foo.py would work.

This makes it so that "uncategorized" plug-ins in the top level of a
directory such as action_plugins will be loaded, though plug-ins in a
"category" subdirectory will still be preferred.  For example,
action_plugins/bar/foo.py would be preferred over action_plugins/foo.py.

Fix typo in npm module documentation preventing it to be processed by an...

Fix typo in git module documentation preventing it to be processed by an...

Module for managing users, tenants, and roles within OpenStack.

If a variable was provided for an include, in either of these ways:

    ---
    - hosts: all
      tasks:
      - include: included.yml param=www-data
      - include: included.yml
        vars:
          param: www-data

and then that param was used as the value of sudo_user in the included
tasks:

    ---
    - name: do something as a parameterized sudo_user
      command: whoami
      sudo: yes
      sudo_user: $param

you would receive a "failed to parse: usage: sudo" error back and the
command would not execute.

This seemed to be due to a missing call to template.template somewhere,
because the final value being passed through ssh was still `$param`.
After some digging, the issue seems to instead have been a problem with
providing the wrong context to the template for expansion. Inside the
`Task` logic, it was passing `play.vars` as the context, where
`module_vars` seemed more appropriate. After replacing it, my test case
above ran without issue. There was a comment above suggesting that the
template call might be unnecessary, but removing it made the original
error return, since it is not getting escaped later down the line. I
removed the comment since it was inaccurate.

I tried to actually incorporate my test case above into the test suite
as a regression test, but was unable to figure out how to structure it.
The existing test infrastructure seemed to only be testing for correct
number of counts in things (ok vs. changed, etc.), without regard for
whether the content generated by the command is correct. If there is an
example of a test similar to this one (where I would want to check the
JSON generated to make sure sudo_user had been converted), please let me
know and I will be happy to submit an additional patch.