Add tox integration to run unittests in supported python releases.
Travis-CI is used for test execution.
Additionally, the unittest TestQuotePgIdentifier was updated to support
using assert_raises_regexp on python-2.6.
Sample travis-ci output available at
https://travis-ci.org/ansible/ansible/builds/54189977
Was using persist_files=True when specifying the create paramater,
which breaks pipelining. Switched to use delete_remote_tmp=False instead,
which is the proper way to preserve the remove tmp dir when running
other modules from the action plugin.
Note: In v1 we fix this by transforming into unicode just before we use
it (when we send it to jinja2) because jinja2 cannot handle non-ascii
characters in str.
In v2 our model is that all text values need to be stored as unicode
type internally. So we transform this to unicode when we read it from
the inventory file and save it into the internal dict instead.
- become constants inherit existing sudo/su ones
- become command line options, marked sudo/su as deprecated and moved sudo/su passwords to runas group
- changed method signatures as privlege escalation is collapsed to become
- added tests for su and become, diabled su for lack of support in local.py
- updated playbook,play and task objects to become
- added become to runner
- added whoami test for become/sudo/su
- added home override dir for plugins
- removed useless method from ask pass
- forced become pass to always be string also uses to_bytes
- fixed fakerunner for tests
- corrected reference in synchronize action plugin
- added pfexec (needs testing)
- removed unused sudo/su in runner init
- removed deprecated info
- updated pe tests to allow to run under sudo and not need root
- normalized become options into a funciton to avoid duplication and inconsistencies
- pushed suppored list to connection classs property
- updated all connection plugins to latest 'become' pe
- includes fixes from feedback (including typos)
- added draft docs
- stub of become_exe, leaving for future v2 fixes
New users might think that "state=started" implies that the service is also started at boot-time, which isn't.
By adding it, this change makes a clear distinction between the service state, and whether it is enabled (at boot).
And makes the example more feature-complete as this is what most people would be doing anyway.
