1
0
Fork 0
mirror of https://github.com/ansible-collections/community.general.git synced 2024-09-14 20:13:21 +02:00
Find a file
Monty Taylor efb989a50c Consume standard OpenStack environment settings
The OpenStack client utilities consume a set of input environment
variables for things like username and auth_url, so it's very
common for OpenStack users to have such settings set in their
environment. Indeed, things like devstack also output a shell file
to be sourced to set them. Although in a playbook it's entirely
expected that variables should be used to pass in system settings
like api passwords, for ad-hoc command line usage, needing to pass
in five parameters which are almost certainly in the environment
already reduces the utility.

Grab the environment variables and inject them as default. Special care
is taken to ensure that in the case where the values are not found, the
behavior of which parameters are required is not altered.
2014-08-04 20:52:29 -07:00
bin Ignore powershell implementation files with ansible-doc as documentation lives in Python stubs. 2014-07-28 12:13:30 -04:00
docs/man Update test strategies guide. 2014-05-26 08:12:39 -04:00
docsite Update version. 2014-08-01 19:43:54 -04:00
examples Added script for configuring winrm for Ansible 2014-07-06 19:02:32 +02:00
hacking Add checkmode support for test-module script 2014-07-20 13:54:30 -05:00
legacy Various tests using datafiles are being moved into the integration test framework (tests_new right now). 2014-02-20 17:16:58 -05:00
lib/ansible Make run_command process communication smarter 2014-08-04 15:32:41 -05:00
library Consume standard OpenStack environment settings 2014-08-04 20:52:29 -07:00
packaging Require python-crypto >= 2.6 for debian package builds 2014-08-04 13:17:25 -04:00
plugins Envirionment variable support in GCE inventory plugin. 2014-08-01 16:12:57 -05:00
test Merge pull request #8426 from jlaska/update_integration_Makefile 2014-08-04 13:42:01 -04:00
.gitignore Updated DEB build workflow 2014-06-20 16:09:02 -04:00
CHANGELOG.md Backporting CHANGELOG/RELEASES and packaging updates for 1.6.7-8 releases 2014-07-22 17:26:15 -05:00
CODING_GUIDELINES.md CODING_GUIDELINES: Fix typo: / => \ 2014-06-28 08:21:15 -07:00
CONTRIBUTING.md Fix small typographic error 2014-06-25 22:10:59 +02:00
COPYING license file should be in source tree 2012-03-15 20:24:22 -04:00
Makefile Correct Makefile variable usage 2014-06-20 19:59:09 -04:00
MANIFEST.in Merge pull request #6824 from sivel/make-rpm-from-release 2014-06-23 13:04:51 -05:00
README.md Update README.md 2014-06-06 09:24:33 -04:00
RELEASES.txt Backporting CHANGELOG/RELEASES and packaging updates for 1.6.7-8 releases 2014-07-22 17:26:15 -05:00
setup.py Correct string concatenation error 2014-07-17 08:57:47 -04:00
VERSION Version bump for 1.7 2014-05-05 16:37:46 -05:00

PyPI version PyPI downloads

Ansible

Ansible is a radically simple configuration-management, application deployment, task-execution, and multinode orchestration engine.

Read the documentation and more at http://ansible.com/

Many users run straight from the development branch (it's generally fine to do so), but you might also wish to consume a release. You can find instructions here for a variety of platforms. If you want a tarball of the last release, go to releases.ansible.com and you can also install with pip.

Design Principles

  • Have a dead simple setup process and a minimal learning curve
  • Be super fast & parallel by default
  • Require no server or client daemons; use existing SSHd
  • Use a language that is both machine and human friendly
  • Focus on security and easy auditability/review/rewriting of content
  • Manage remote machines instantly, without bootstrapping
  • Allow module development in any dynamic language, not just Python
  • Be usable as non-root
  • Be the easiest IT automation system to use, ever.

Get Involved

  • Read Contributing.md for all kinds of ways to contribute to and interact with the project, including mailing list information and how to submit bug reports and code to Ansible.
  • All code submissions are done through pull requests. Take care to make sure no merge commits are in the submission, and use "git rebase" vs "git merge" for this reason. If submitting a large code change (other than modules), it's probably a good idea to join ansible-devel and talk about what you would like to do or add first and to avoid duplicate efforts. This not only helps everyone know what's going on, it also helps save time and effort if we decide some changes are needed.
  • irc.freenode.net: #ansible

Branch Info

  • Releases are named after Van Halen songs.
  • The devel branch corresponds to the release actively under development.
  • Various release-X.Y branches exist for previous releases
  • We'd love to have your contributions, read "CONTRIBUTING.md" for process notes.

Author

Ansible was created by Michael DeHaan (michael@ansible.com) and has contributions from over 700 users (and growing). Thanks everyone!

Ansible, Inc