ansible/community.general
1
0
Fork 0
mirror of https://github.com/ansible-collections/community.general.git synced 2024-09-14 20:13:21 +02:00
Code Releases Activity
Mirror of https://github.com/ansible-collections/community.general.git
1813 commits 10 branches 167 tags 272 MiB
Python 99.5%
Shell 0.3%
HCL 0.1%
Find a file
Dag Wieers d158218c3f Add /proc/cmdline information to the default facts 
The use-case here is that based on information in the /proc/cmdline certain actions can be taken.

A practical example in our case is that we have a play at the end of the provisioning phase that reboots the system. Since we don't want to accidentally reboot a system (or restart the network) on a production machine, having a way to separate an Anaconda post-install (sshd in chroot) with a normal system is a good way to make that distinction.

    ---
    - name: reboot
      hosts: all
      tasks:
      - action: command init 6
        only_if: "not '${ansible_cmdline.BOOT_IMAGE}'.startswith('$')"

A practical problem here is the fact that we cannot simply check whether it is set or empty:

    ---
    - name: reboot
      hosts: all
      tasks:
      - action: command init 6
        only_if: "'${ansible_cmdline.BOOT_IMAGE}'"

If ansible_cmdline was a string, a simple only_if: "'${ansible_cmdline}'.find(' BOOT_IMAGE=')" was an option, but still not very "beautiful" :-/

This implementation uses shlex.split() and uses split(sep, maxsplit=1).
2012-09-06 09:35:33 +02:00
bin make callbacks modular 2012-08-18 19:43:08 -04:00
docs/man Fully document the -v option. 2012-08-15 10:13:38 -04:00
examples update playbook example 2012-08-28 20:27:17 -04:00
hacking Allow unicode transfer by not base64 encoding. Also: faster 2012-08-02 21:20:43 -04:00
lib/ansible backuplocal => backup_local for API standardization reasons 2012-09-04 19:49:49 -04:00
library Add /proc/cmdline information to the default facts 2012-09-06 09:35:33 +02:00
packaging added freebsd ports package 2012-08-29 09:46:16 -04:00
test - Makefile now works with freebsd (date command options are diff) 2012-08-29 09:46:05 -04:00
.gitignore clean exec bits from lib/ansible/*.py, ignore Eclipse/PyDev files 2012-04-14 21:35:51 +02:00
CHANGELOG.md update changelog 2012-09-04 20:38:06 -04:00
COPYING license file should be in source tree 2012-03-15 20:24:22 -04:00
Makefile - Makefile now works with freebsd (date command options are diff) 2012-08-29 09:46:05 -04:00
MANIFEST.in Add some docs/examples 2012-08-14 13:05:44 -04:00
README.md update changelog 2012-08-06 21:15:39 -04:00
RELEASES.txt Add list of releases 2012-08-06 21:32:49 -04:00
setup.py Update setup.py 2012-08-21 20:38:20 -04:00
VERSION Release bump 2012-08-06 19:55:27 -04:00

README.md

Ansible

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

Read the documentation at http://ansible.github.com

Design Principles

  • Dead simple setup
  • Super fast & parallel by default
  • No server or client daemons; use existing SSHd
  • No additional software required on client boxes
  • Modules can be written in ANY language
  • Awesome API for creating very powerful distributed scripts
  • Be usable as non-root
  • The easiest config management system to use, ever.

Get Involved

Branch Info

  • Releases are named after Van Halen songs.
  • The devel branch corresponds to release 0.7, "Panama".
  • Various release-X.Y branches exist for previous releases
  • All feature work happens on the development branch.
  • Major bug fixes will be made to the last release branch only
  • See CHANGELOG.md for release notes to track each release.

Patch Instructions

Contributions to the core and modules are greatly welcome.

  • Required Process:
    • Submit github pull requests to the "ansible/devel" branch for features
    • Fixes for bugs may also be submitted to "ansible/release-X.Y" for the last release
    • Make sure "make tests" passes before submitting any requests.
  • Bonus points:
    • Joining the mailing list
    • Fixing bugs instead of sending bug reports.
    • Using squash merges
    • Updating the "rst/*" files in the docs project and "docs/" manpage content
    • Adding more unit tests
  • Avoid:
    • Sending patches to the mailing list directly.
    • Sending feature pull requests to the 'release' branch instead of the devel branch
    • Sending pull requests to mpdehaan's personal ansible fork.

Author

Michael DeHaan -- michael.dehaan@gmail.com

http://michaeldehaan.net