Compare commits
84 Commits
| Author | SHA1 | Date | |
|---|---|---|---|
| 43bd7f6b44 | |||
| 4a99568fa3 | |||
| eef7bf7e4b | |||
| a8e3306e9e | |||
| fa58e635bc | |||
| 3d263f8330 | |||
| cb82ddec02 | |||
| 9e1fd8f2f0 | |||
| 93a5f75ae3 | |||
| 6bc377e3f0 | |||
| 8416f4584d | |||
| e53aefddaa | |||
| b4bd9a6761 | |||
| aa37f3cf25 | |||
| beb04bc264 | |||
| 080c3ce90c | |||
| 249f88db80 | |||
| 14c0916f0a | |||
| 69d08cf8de | |||
| a3ded0e8e3 | |||
| d921f2206c | |||
| 49c05da2d2 | |||
| 01b7d928aa | |||
| cf15cd7d44 | |||
| 865be9a4b7 | |||
| 1acaaadd0b | |||
| ac8f2a5db8 | |||
| fc130b6bfc | |||
| 1609a5d1cc | |||
| b8877d2d8b | |||
| 7239d2d371 | |||
| 5cdfe667d6 | |||
| de07dc85f5 | |||
| 6bf67bb4c8 | |||
| 093d26b2a2 | |||
| 82e5816aac | |||
| 6dca8f593f | |||
| dcdb718f7a | |||
| f17b564448 | |||
| a130acec4e | |||
| 95b1e0b022 | |||
| b51538ffbe | |||
| 7f0b39271c | |||
| e9f685f39f | |||
| 150def6015 | |||
| 6809f986fc | |||
| 28ed180234 | |||
| 8191ea534e | |||
| 19fd0d6787 | |||
| 62b7d211b3 | |||
| b4b600a70b | |||
| 7d48bef252 | |||
| e7f64ed9d5 | |||
| 4a2fe5134c | |||
| 53b685fd6d | |||
| 5a225f9e95 | |||
| 4cbdf02efe | |||
| 0f8441ad83 | |||
| 6a8d192649 | |||
| 223a6ee8eb | |||
| 12308ba054 | |||
| cf6df70765 | |||
| 470be95257 | |||
| 33f8460a78 | |||
| 94a87bd92a | |||
| 5b8ffe66a2 | |||
| ae2a1f403a | |||
| 25de85e95b | |||
| a2ceacd75d | |||
| a22c7d8f3b | |||
| 2d4d354cb1 | |||
| dd45caa7a9 | |||
| 6f20fe3599 | |||
| 60f48ad1a3 | |||
| 63413cb0d4 | |||
| 10f4d6b982 | |||
| b42dcee567 | |||
| aaeb2c0b08 | |||
| b660c7ec1e | |||
| 71f3f1601a | |||
| a5010e1630 | |||
| bff040a0b6 | |||
| f2246d3a3f | |||
| 5698f942c9 |
@ -46,7 +46,6 @@ stages:
|
||||
targets:
|
||||
- test: 1
|
||||
- test: 2
|
||||
- test: 3
|
||||
- stage: Units
|
||||
dependsOn: []
|
||||
jobs:
|
||||
@ -92,10 +91,8 @@ stages:
|
||||
test: rhel/8.6@3.9
|
||||
- name: RHEL 9.0
|
||||
test: rhel/9.0
|
||||
- name: FreeBSD 12.3
|
||||
test: freebsd/12.3
|
||||
- name: FreeBSD 13.1
|
||||
test: freebsd/13.1
|
||||
- name: FreeBSD 13.2
|
||||
test: freebsd/13.2
|
||||
groups:
|
||||
- 1
|
||||
- 2
|
||||
@ -108,8 +105,8 @@ stages:
|
||||
test: rhel/8.6
|
||||
- name: RHEL 9.0
|
||||
test: rhel/9.0
|
||||
- name: FreeBSD 13.1
|
||||
test: freebsd/13.1
|
||||
- name: FreeBSD 13.2
|
||||
test: freebsd/13.2
|
||||
groups:
|
||||
- 3
|
||||
- 4
|
||||
|
||||
@ -16,14 +16,8 @@ group2_include=(
|
||||
validate-modules
|
||||
)
|
||||
|
||||
group3_include=(
|
||||
docs-build
|
||||
sanity-docs
|
||||
)
|
||||
|
||||
group1_exclude=(
|
||||
"${group2_include[@]}"
|
||||
"${group3_include[@]}"
|
||||
)
|
||||
|
||||
options=()
|
||||
@ -39,11 +33,6 @@ case "${group}" in
|
||||
options+=(--test "${name}")
|
||||
done
|
||||
;;
|
||||
3)
|
||||
for name in "${group3_include[@]}"; do
|
||||
options+=(--test "${name}")
|
||||
done
|
||||
;;
|
||||
esac
|
||||
|
||||
# shellcheck disable=SC2086
|
||||
|
||||
151
.github/BOTMETA.yml
vendored
151
.github/BOTMETA.yml
vendored
@ -1,151 +0,0 @@
|
||||
automerge: false
|
||||
collection_redirect: true
|
||||
notifications: false
|
||||
files:
|
||||
$module_utils/csharp: &id001
|
||||
labels: windows
|
||||
maintainers: $team_windows_core
|
||||
support: core
|
||||
$module_utils/network:
|
||||
labels: networking
|
||||
$module_utils/network/common:
|
||||
maintainers: $team_networking
|
||||
support: network
|
||||
$module_utils/powershell: *id001
|
||||
$modules:
|
||||
ignored: ryansb tomaszkiewicz
|
||||
$modules/lineinfile.py: $team_ansible samdoran
|
||||
$modules/stat.py:
|
||||
ignored: bpennypacker
|
||||
$modules/unarchive.py:
|
||||
ignored: dagwieers
|
||||
labels: m:unarchive
|
||||
maintainers: pileofrogs
|
||||
$modules/add_host.py:
|
||||
ignored: skvidal
|
||||
maintainers: $team_ansible
|
||||
$modules/get_url.py: ptux
|
||||
$modules/uri.py:
|
||||
ignored: romeotheriault
|
||||
maintainers: $team_ansible
|
||||
$modules/pip.py: Lujeni webknjaz
|
||||
$modules//yum.py:
|
||||
ignored: skvidal
|
||||
maintainers: $team_ansible kustodian
|
||||
$modules/user.py: $team_ansible samdoran
|
||||
$modules/pause.py: samdoran
|
||||
$modules/wait_for.py: gregswift
|
||||
$plugins/cliconf/:
|
||||
labels: networking
|
||||
$plugins/connection/psrp.py: *id001
|
||||
$plugins/connection/winrm.py: *id001
|
||||
$plugins/doc_fragments/url_windows.py:
|
||||
labels: windows
|
||||
maintainers: $team_windows_core
|
||||
support: core
|
||||
$plugins/httpapi:
|
||||
labels: networking
|
||||
maintainers: $team_networking
|
||||
support: network
|
||||
$plugins/netconf/:
|
||||
labels: networking
|
||||
maintainers: $team_networking
|
||||
support: network
|
||||
$plugins/shell/powershell.py: *id001
|
||||
$plugins/terminal/:
|
||||
labels: networking
|
||||
$plugins/terminal/__init__.py:
|
||||
support: network
|
||||
.github/BOTMETA.yml:
|
||||
labels: botmeta
|
||||
support: core
|
||||
docs/:
|
||||
maintainers:
|
||||
- acozine
|
||||
docs/docsite/rst/community/:
|
||||
maintainers:
|
||||
- gundalow
|
||||
docs/docsite/rst/dev_guide/:
|
||||
maintainers:
|
||||
- gundalow
|
||||
docs/docsite/rst/network/:
|
||||
labels: networking
|
||||
maintainers:
|
||||
- samccann
|
||||
docs/docsite/rst/user_guide/windows: *id001
|
||||
hacking/report.py:
|
||||
notified: mattclay
|
||||
hacking/shippable/:
|
||||
notified: mattclay
|
||||
lib/ansible/cli/scripts/ansible_connection_cli_stub.py:
|
||||
keywords:
|
||||
- persistent connection
|
||||
labels: networking
|
||||
lib/ansible/config/ansible_builtin_runtime.yml:
|
||||
labels: runtime
|
||||
maintainers: gundalow
|
||||
lib/ansible/executor/powershell: *id001
|
||||
lib/ansible/inventory:
|
||||
keywords:
|
||||
- core inventory
|
||||
- inventory
|
||||
- inventory parsing
|
||||
lib/ansible/playbook/handler.py:
|
||||
keywords:
|
||||
- handlers
|
||||
lib/ansible/playbook/role:
|
||||
keywords:
|
||||
- roles path
|
||||
- roles_path
|
||||
- role
|
||||
- role path
|
||||
lib/ansible/playbook/role/include.py:
|
||||
keywords:
|
||||
- include role
|
||||
- include_role
|
||||
- role include
|
||||
lib/ansible/playbook/role/requirement.py:
|
||||
keywords:
|
||||
- role dependencies
|
||||
- role dep
|
||||
- role dependency
|
||||
lib/ansible/release.py:
|
||||
notified: mattclay nitzmahone
|
||||
lib/ansible/template:
|
||||
keywords:
|
||||
- jinja
|
||||
- jinja2
|
||||
lib/ansible/utils/collection_loader.py:
|
||||
notified: mattclay nitzmahone
|
||||
test/integration/targets/incidental_:
|
||||
notified: mattclay
|
||||
test/lib/:
|
||||
notified: mattclay
|
||||
test/lib/ansible_test/_util/controller/sanity/validate-modules:
|
||||
keywords:
|
||||
- validate-modules
|
||||
notified:
|
||||
- mattclay
|
||||
test/lib/ansible_test/_util/controller/sanity/validate-modules/validate_modules/main.py:
|
||||
notified:
|
||||
- gundalow
|
||||
- sivel
|
||||
test/lib/ansible_test/_util/controller/sanity/validate-modules/validate_modules/schema.py:
|
||||
notified:
|
||||
- gundalow
|
||||
- sivel
|
||||
test/sanity/:
|
||||
notified: mattclay
|
||||
test/sanity/ignore.txt:
|
||||
notified: tremble
|
||||
test/support/:
|
||||
notified: mattclay
|
||||
test/utils/shippable/:
|
||||
notified: mattclay
|
||||
macros:
|
||||
module_utils: lib/ansible/module_utils
|
||||
modules: lib/ansible/modules
|
||||
plugins: lib/ansible/plugins
|
||||
team_ansible: []
|
||||
team_networking: Qalthos ganeshrn trishnaguha justjais NilashishC danielmellado rohitthakur2590 GomathiselviS
|
||||
team_windows_core: nitzmahone jborean93
|
||||
3
.github/CODEOWNERS
vendored
3
.github/CODEOWNERS
vendored
@ -1,3 +0,0 @@
|
||||
/docs/ @ansible/ansible-release-managers
|
||||
/examples/ @ansible/ansible-release-managers
|
||||
/hacking/ @ansible/ansible-release-managers
|
||||
61
MANIFEST.in
61
MANIFEST.in
@ -1,55 +1,12 @@
|
||||
include README.rst
|
||||
include COPYING
|
||||
include SYMLINK_CACHE.json
|
||||
include requirements.txt
|
||||
recursive-include docs *
|
||||
include docs/docsite/rst/collections/all_plugins.rst
|
||||
exclude docs/docsite/rst_warnings
|
||||
exclude docs/docsite/rst/conf.py
|
||||
exclude docs/docsite/rst/index.rst
|
||||
exclude docs/docsite/rst/dev_guide/index.rst
|
||||
exclude docs/docsite/rst/dev_guide/testing/sanity/bin-symlinks.rst
|
||||
exclude docs/docsite/rst/dev_guide/testing/sanity/botmeta.rst
|
||||
exclude docs/docsite/rst/dev_guide/testing/sanity/integration-aliases.rst
|
||||
exclude docs/docsite/rst/dev_guide/testing/sanity/release-names.rst
|
||||
recursive-exclude docs/docsite/_build *
|
||||
recursive-exclude docs/docsite/_extensions *.pyc *.pyo
|
||||
include examples/hosts
|
||||
include examples/ansible.cfg
|
||||
include examples/scripts/ConfigureRemotingForAnsible.ps1
|
||||
include examples/scripts/upgrade_to_ps3.ps1
|
||||
include lib/ansible/keyword_desc.yml
|
||||
recursive-include lib/ansible/executor/powershell *.ps1
|
||||
recursive-include lib/ansible/module_utils/csharp *.cs
|
||||
recursive-include lib/ansible/module_utils/powershell *.psm1
|
||||
recursive-include lib/ansible/modules/windows *.ps1
|
||||
recursive-include lib/ansible/galaxy/data *.yml *.j2 README.md ansible.cfg inventory .git_keep
|
||||
recursive-include lib/ansible/config *.yml
|
||||
recursive-include lib/ansible/modules *.yml
|
||||
recursive-include lib/ansible/plugins/test *.yml
|
||||
recursive-include lib/ansible/plugins/filter *.yml
|
||||
recursive-include licenses *.txt
|
||||
recursive-include packaging Makefile *.py *.j2
|
||||
recursive-include test/ansible_test *.py Makefile
|
||||
recursive-include test/integration *
|
||||
recursive-include test/lib/ansible_test/config *.yml *.template
|
||||
recursive-include test/lib/ansible_test/_data *.cfg *.in *.ini *.ps1 *.txt *.yml coveragerc
|
||||
recursive-include test/lib/ansible_test/_util *.cfg *.ini *.json *.ps1 *.psd1 *.py *.sh *.txt *.yml
|
||||
recursive-include test/lib/ansible_test/_util/controller/sanity/validate-modules validate-modules
|
||||
recursive-include test/sanity *.in *.json *.py *.txt
|
||||
recursive-include test/support *.py *.ps1 *.psm1 *.cs *.md
|
||||
exclude test/sanity/code-smell/botmeta.*
|
||||
exclude test/sanity/code-smell/release-names.*
|
||||
exclude test/lib/ansible_test/_internal/commands/sanity/bin_symlinks.py
|
||||
exclude test/lib/ansible_test/_internal/commands/sanity/integration_aliases.py
|
||||
recursive-include test/units *
|
||||
include Makefile
|
||||
include MANIFEST.in
|
||||
include bin/*
|
||||
include changelogs/CHANGELOG*.rst
|
||||
include changelogs/changelog.yaml
|
||||
recursive-include hacking/build_library *.py
|
||||
include hacking/build-ansible.py
|
||||
include hacking/templates/*.j2
|
||||
include hacking/test-module.py
|
||||
include hacking/update-sanity-requirements.py
|
||||
include bin/*
|
||||
include licenses/*.txt
|
||||
include requirements.txt
|
||||
recursive-include packaging *.py *.j2
|
||||
recursive-include test/ansible_test *.py Makefile
|
||||
recursive-include test/integration *
|
||||
recursive-include test/sanity *.in *.json *.py *.txt
|
||||
recursive-include test/support *.py *.ps1 *.psm1 *.cs *.md
|
||||
recursive-include test/units *
|
||||
|
||||
157
Makefile
157
Makefile
@ -1,157 +0,0 @@
|
||||
# WARN: gmake syntax
|
||||
########################################################
|
||||
# Makefile for Ansible
|
||||
#
|
||||
# useful targets:
|
||||
# make clean ---------------- clean up
|
||||
# make sdist ---------------- produce a tarball
|
||||
# make tests ---------------- run the tests (see https://docs.ansible.com/ansible/devel/dev_guide/testing_units.html for requirements)
|
||||
|
||||
########################################################
|
||||
# variable section
|
||||
|
||||
NAME = ansible-core
|
||||
OS = $(shell uname -s)
|
||||
PREFIX ?= '/usr/local'
|
||||
SDIST_DIR ?= 'dist'
|
||||
|
||||
# This doesn't evaluate until it's called. The -D argument is the
|
||||
# directory of the target file ($@), kinda like `dirname`.
|
||||
MANPAGES ?= $(patsubst %.rst.in,%,$(wildcard ./docs/man/man1/ansible*.1.rst.in))
|
||||
ifneq ($(shell command -v rst2man 2>/dev/null),)
|
||||
ASCII2MAN = rst2man $< $@
|
||||
else ifneq ($(shell command -v rst2man.py 2>/dev/null),)
|
||||
ASCII2MAN = rst2man.py $< $@
|
||||
else
|
||||
ASCII2MAN = @echo "ERROR: rst2man from docutils command is not installed but is required to build $(MANPAGES)" && exit 1
|
||||
endif
|
||||
|
||||
PYTHON ?= python
|
||||
GENERATE_CLI = packaging/pep517_backend/_generate_man.py
|
||||
|
||||
# fetch version from project release.py as single source-of-truth
|
||||
VERSION := $(shell $(PYTHON) packaging/release/versionhelper/version_helper.py --raw || echo error)
|
||||
ifeq ($(findstring error,$(VERSION)), error)
|
||||
$(error "version_helper failed")
|
||||
endif
|
||||
|
||||
# ansible-test parameters
|
||||
ANSIBLE_TEST ?= bin/ansible-test
|
||||
TEST_FLAGS ?=
|
||||
|
||||
# ansible-test units parameters (make test / make test-py3)
|
||||
PYTHON_VERSION ?= $(shell python2 -c 'import sys; print("%s.%s" % sys.version_info[:2])')
|
||||
PYTHON3_VERSION ?= $(shell python3 -c 'import sys; print("%s.%s" % sys.version_info[:2])')
|
||||
|
||||
# ansible-test integration parameters (make integration)
|
||||
IMAGE ?= centos7
|
||||
TARGET ?=
|
||||
|
||||
########################################################
|
||||
|
||||
.PHONY: all
|
||||
all: clean python
|
||||
|
||||
.PHONY: tests
|
||||
tests:
|
||||
$(ANSIBLE_TEST) units -v --python $(PYTHON_VERSION) $(TEST_FLAGS)
|
||||
|
||||
.PHONY: tests-py3
|
||||
tests-py3:
|
||||
$(ANSIBLE_TEST) units -v --python $(PYTHON3_VERSION) $(TEST_FLAGS)
|
||||
|
||||
.PHONY: integration
|
||||
integration:
|
||||
$(ANSIBLE_TEST) integration -v --docker $(IMAGE) $(TARGET) $(TEST_FLAGS)
|
||||
|
||||
# Regenerate %.1.rst if %.1.rst.in has been modified more
|
||||
# recently than %.1.rst.
|
||||
%.1.rst: %.1.rst.in
|
||||
sed "s/%VERSION%/$(VERSION)/" $< > $@
|
||||
rm $<
|
||||
|
||||
# Regenerate %.1 if %.1.rst or release.py has been modified more
|
||||
# recently than %.1. (Implicitly runs the %.1.rst recipe)
|
||||
%.1: %.1.rst lib/ansible/release.py
|
||||
$(ASCII2MAN)
|
||||
|
||||
.PHONY: clean
|
||||
clean:
|
||||
@echo "Cleaning up distutils stuff"
|
||||
rm -rf build
|
||||
rm -rf dist
|
||||
rm -rf lib/ansible*.egg-info/
|
||||
@echo "Cleaning up byte compiled python stuff"
|
||||
find . -type f -regex ".*\.py[co]$$" -delete
|
||||
find . -type d -name "__pycache__" -delete
|
||||
@echo "Cleaning up editor backup files"
|
||||
find . -type f -not -path ./test/units/inventory_test_data/group_vars/noparse/all.yml~ \( -name "*~" -or -name "#*" \) -delete
|
||||
find . -type f \( -name "*.swp" \) -delete
|
||||
@echo "Cleaning up manpage stuff"
|
||||
find ./docs/man -type f -name "*.xml" -delete
|
||||
find ./docs/man -type f -name "*.rst" -delete
|
||||
find ./docs/man/man3 -type f -name "*.3" -delete
|
||||
rm -f ./docs/man/man1/*
|
||||
@echo "Cleaning up output from test runs"
|
||||
rm -rf test/test_data
|
||||
rm -rf logs/
|
||||
rm -rf .cache/
|
||||
rm -f test/units/.coverage*
|
||||
rm -rf test/results/*/*
|
||||
find test/ -type f -name '*.retry' -delete
|
||||
@echo "Cleaning up symlink cache"
|
||||
rm -f SYMLINK_CACHE.json
|
||||
rm -rf docs/json
|
||||
rm -rf docs/js
|
||||
@echo "Cleaning up docsite"
|
||||
$(MAKE) -C docs/docsite clean
|
||||
|
||||
.PHONY: python
|
||||
python:
|
||||
$(PYTHON) setup.py build
|
||||
|
||||
.PHONY: install
|
||||
install:
|
||||
$(PYTHON) setup.py install
|
||||
|
||||
.PHONY: install_manpages
|
||||
install_manpages:
|
||||
gzip -9 $(wildcard ./docs/man/man1/ansible*.1)
|
||||
cp $(wildcard ./docs/man/man1/ansible*.1.gz) $(PREFIX)/man/man1/
|
||||
|
||||
.PHONY: sdist_check
|
||||
sdist_check:
|
||||
$(PYTHON) -c 'import setuptools, sys; sys.exit(int(not (tuple(map(int, setuptools.__version__.split("."))) > (39, 2, 0))))'
|
||||
$(PYTHON) packaging/sdist/check-link-behavior.py
|
||||
|
||||
.PHONY: sdist
|
||||
sdist: sdist_check clean docs
|
||||
_ANSIBLE_SDIST_FROM_MAKEFILE=1 $(PYTHON) setup.py sdist --dist-dir=$(SDIST_DIR)
|
||||
|
||||
# Official releases generate the changelog as the last commit before the release.
|
||||
# Snapshots shouldn't result in new checkins so the changelog is generated as
|
||||
# part of creating the tarball.
|
||||
.PHONY: snapshot
|
||||
snapshot: sdist_check clean docs changelog
|
||||
_ANSIBLE_SDIST_FROM_MAKEFILE=1 $(PYTHON) setup.py sdist --dist-dir=$(SDIST_DIR)
|
||||
|
||||
.PHONY: sdist_upload
|
||||
sdist_upload: clean docs
|
||||
$(PYTHON) setup.py sdist upload 2>&1 |tee upload.log
|
||||
|
||||
.PHONY: changelog
|
||||
changelog:
|
||||
PYTHONPATH=./lib antsibull-changelog release -vv --use-ansible-doc && PYTHONPATH=./lib antsibull-changelog generate -vv --use-ansible-doc
|
||||
|
||||
.PHONY: generate_rst
|
||||
generate_rst: lib/ansible/cli/*.py
|
||||
mkdir -p ./docs/man/man1/ ; \
|
||||
$(PYTHON) $(GENERATE_CLI) --template-file=packaging/pep517_backend/_templates/man.j2 --output-dir=docs/man/man1/ --output-format man lib/ansible/cli/*.py
|
||||
|
||||
.PHONY: docs
|
||||
docs: generate_rst
|
||||
$(MAKE) $(MANPAGES)
|
||||
|
||||
.PHONY: version
|
||||
version:
|
||||
@echo $(VERSION)
|
||||
89
README.md
Normal file
89
README.md
Normal file
@ -0,0 +1,89 @@
|
||||
[](https://pypi.org/project/ansible-core)
|
||||
[](https://docs.ansible.com/ansible/latest/)
|
||||
[](https://docs.ansible.com/ansible/latest/community/communication.html)
|
||||
[](https://dev.azure.com/ansible/ansible/_build/latest?definitionId=20&branchName=devel)
|
||||
[](https://docs.ansible.com/ansible/latest/community/code_of_conduct.html)
|
||||
[](https://docs.ansible.com/ansible/latest/community/communication.html#mailing-list-information)
|
||||
[](COPYING)
|
||||
[](https://bestpractices.coreinfrastructure.org/projects/2372)
|
||||
|
||||
# Ansible
|
||||
|
||||
Ansible is a radically simple IT automation system. It handles
|
||||
configuration management, application deployment, cloud provisioning,
|
||||
ad-hoc task execution, network automation, and multi-node orchestration. Ansible makes complex
|
||||
changes like zero-downtime rolling updates with load balancers easy. More information on the Ansible [website](https://ansible.com/).
|
||||
|
||||
## Design Principles
|
||||
|
||||
* Have an extremely simple setup process with a minimal learning curve.
|
||||
* Manage machines quickly and in parallel.
|
||||
* Avoid custom-agents and additional open ports, be agentless by
|
||||
leveraging the existing SSH daemon.
|
||||
* Describe infrastructure in a language that is both machine and human
|
||||
friendly.
|
||||
* Focus on security and easy auditability/review/rewriting of content.
|
||||
* Manage new remote machines instantly, without bootstrapping any
|
||||
software.
|
||||
* Allow module development in any dynamic language, not just Python.
|
||||
* Be usable as non-root.
|
||||
* Be the easiest IT automation system to use, ever.
|
||||
|
||||
## Use Ansible
|
||||
|
||||
You can install a released version of Ansible with `pip` or a package manager. See our
|
||||
[installation guide](https://docs.ansible.com/ansible/latest/installation_guide/intro_installation.html) for details on installing Ansible
|
||||
on a variety of platforms.
|
||||
|
||||
Power users and developers can run the `devel` branch, which has the latest
|
||||
features and fixes, directly. Although it is reasonably stable, you are more likely to encounter
|
||||
breaking changes when running the `devel` branch. We recommend getting involved
|
||||
in the Ansible community if you want to run the `devel` branch.
|
||||
|
||||
## Get Involved
|
||||
|
||||
* Read [Community Information](https://docs.ansible.com/ansible/latest/community) 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.
|
||||
* Join a [Working Group](https://github.com/ansible/community/wiki),
|
||||
an organized community devoted to a specific technology domain or platform.
|
||||
* Submit a proposed code update through a pull request to the `devel` branch.
|
||||
* Talk to us before making larger changes
|
||||
to avoid duplicate efforts. This not only helps everyone
|
||||
know what is going on, but it also helps save time and effort if we decide
|
||||
some changes are needed.
|
||||
* For a list of email lists, IRC channels and Working Groups, see the
|
||||
[Communication page](https://docs.ansible.com/ansible/latest/community/communication.html)
|
||||
|
||||
## Coding Guidelines
|
||||
|
||||
We document our Coding Guidelines in the [Developer Guide](https://docs.ansible.com/ansible/devel/dev_guide/). We particularly suggest you review:
|
||||
|
||||
* [Contributing your module to Ansible](https://docs.ansible.com/ansible/devel/dev_guide/developing_modules_checklist.html)
|
||||
* [Conventions, tips, and pitfalls](https://docs.ansible.com/ansible/devel/dev_guide/developing_modules_best_practices.html)
|
||||
|
||||
## Branch Info
|
||||
|
||||
* The `devel` branch corresponds to the release actively under development.
|
||||
* The `stable-2.X` branches correspond to stable releases.
|
||||
* Create a branch based on `devel` and set up a [dev environment](https://docs.ansible.com/ansible/latest/dev_guide/developing_modules_general.html#common-environment-setup) if you want to open a PR.
|
||||
* See the [Ansible release and maintenance](https://docs.ansible.com/ansible/devel/reference_appendices/release_and_maintenance.html) page for information about active branches.
|
||||
|
||||
## Roadmap
|
||||
|
||||
Based on team and community feedback, an initial roadmap will be published for a major or minor version (ex: 2.7, 2.8).
|
||||
The [Ansible Roadmap page](https://docs.ansible.com/ansible/devel/roadmap/) details what is planned and how to influence the roadmap.
|
||||
|
||||
## Authors
|
||||
|
||||
Ansible was created by [Michael DeHaan](https://github.com/mpdehaan)
|
||||
and has contributions from over 5000 users (and growing). Thanks everyone!
|
||||
|
||||
[Ansible](https://www.ansible.com) is sponsored by [Red Hat, Inc.](https://www.redhat.com)
|
||||
|
||||
## License
|
||||
|
||||
GNU General Public License v3.0 or later
|
||||
|
||||
See [COPYING](COPYING) to see the full text.
|
||||
115
README.rst
115
README.rst
@ -1,115 +0,0 @@
|
||||
|PyPI version| |Docs badge| |Chat badge| |Build Status| |Code Of Conduct| |Mailing Lists| |License| |CII Best Practices|
|
||||
|
||||
*******
|
||||
Ansible
|
||||
*******
|
||||
|
||||
Ansible is a radically simple IT automation system. It handles
|
||||
configuration management, application deployment, cloud provisioning,
|
||||
ad-hoc task execution, network automation, and multi-node orchestration. Ansible makes complex
|
||||
changes like zero-downtime rolling updates with load balancers easy. More information on the Ansible `website <https://ansible.com/>`_.
|
||||
|
||||
Design Principles
|
||||
=================
|
||||
|
||||
* Have an extremely simple setup process with a minimal learning curve.
|
||||
* Manage machines quickly and in parallel.
|
||||
* Avoid custom-agents and additional open ports, be agentless by
|
||||
leveraging the existing SSH daemon.
|
||||
* Describe infrastructure in a language that is both machine and human
|
||||
friendly.
|
||||
* Focus on security and easy auditability/review/rewriting of content.
|
||||
* Manage new remote machines instantly, without bootstrapping any
|
||||
software.
|
||||
* Allow module development in any dynamic language, not just Python.
|
||||
* Be usable as non-root.
|
||||
* Be the easiest IT automation system to use, ever.
|
||||
|
||||
Use Ansible
|
||||
===========
|
||||
|
||||
You can install a released version of Ansible with ``pip`` or a package manager. See our
|
||||
`installation guide <https://docs.ansible.com/ansible/latest/installation_guide/intro_installation.html>`_ for details on installing Ansible
|
||||
on a variety of platforms.
|
||||
|
||||
Power users and developers can run the ``devel`` branch, which has the latest
|
||||
features and fixes, directly. Although it is reasonably stable, you are more likely to encounter
|
||||
breaking changes when running the ``devel`` branch. We recommend getting involved
|
||||
in the Ansible community if you want to run the ``devel`` branch.
|
||||
|
||||
Get Involved
|
||||
============
|
||||
|
||||
* Read `Community
|
||||
Information <https://docs.ansible.com/ansible/latest/community>`_ 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.
|
||||
* Join a `Working Group
|
||||
<https://github.com/ansible/community/wiki>`_, an organized community devoted to a specific technology domain or platform.
|
||||
* Submit a proposed code update through a pull request to the ``devel`` branch.
|
||||
* Talk to us before making larger changes
|
||||
to avoid duplicate efforts. This not only helps everyone
|
||||
know what is going on, but it also helps save time and effort if we decide
|
||||
some changes are needed.
|
||||
* For a list of email lists, IRC channels and Working Groups, see the
|
||||
`Communication page <https://docs.ansible.com/ansible/latest/community/communication.html>`_
|
||||
|
||||
Coding Guidelines
|
||||
=================
|
||||
|
||||
We document our Coding Guidelines in the `Developer Guide <https://docs.ansible.com/ansible/devel/dev_guide/>`_. We particularly suggest you review:
|
||||
|
||||
* `Contributing your module to Ansible <https://docs.ansible.com/ansible/devel/dev_guide/developing_modules_checklist.html>`_
|
||||
* `Conventions, tips, and pitfalls <https://docs.ansible.com/ansible/devel/dev_guide/developing_modules_best_practices.html>`_
|
||||
|
||||
Branch Info
|
||||
===========
|
||||
|
||||
* The ``devel`` branch corresponds to the release actively under development.
|
||||
* The ``stable-2.X`` branches correspond to stable releases.
|
||||
* Create a branch based on ``devel`` and set up a `dev environment <https://docs.ansible.com/ansible/latest/dev_guide/developing_modules_general.html#common-environment-setup>`_ if you want to open a PR.
|
||||
* See the `Ansible release and maintenance <https://docs.ansible.com/ansible/devel/reference_appendices/release_and_maintenance.html>`_ page for information about active branches.
|
||||
|
||||
Roadmap
|
||||
=======
|
||||
|
||||
Based on team and community feedback, an initial roadmap will be published for a major or minor version (ex: 2.7, 2.8).
|
||||
The `Ansible Roadmap page <https://docs.ansible.com/ansible/devel/roadmap/>`_ details what is planned and how to influence the roadmap.
|
||||
|
||||
Authors
|
||||
=======
|
||||
|
||||
Ansible was created by `Michael DeHaan <https://github.com/mpdehaan>`_
|
||||
and has contributions from over 5000 users (and growing). Thanks everyone!
|
||||
|
||||
`Ansible <https://www.ansible.com>`_ is sponsored by `Red Hat, Inc.
|
||||
<https://www.redhat.com>`_
|
||||
|
||||
License
|
||||
=======
|
||||
|
||||
GNU General Public License v3.0 or later
|
||||
|
||||
See `COPYING <COPYING>`_ to see the full text.
|
||||
|
||||
.. |PyPI version| image:: https://img.shields.io/pypi/v/ansible-core.svg
|
||||
:target: https://pypi.org/project/ansible-core
|
||||
.. |Docs badge| image:: https://img.shields.io/badge/docs-latest-brightgreen.svg
|
||||
:target: https://docs.ansible.com/ansible/latest/
|
||||
.. |Build Status| image:: https://dev.azure.com/ansible/ansible/_apis/build/status/CI?branchName=devel
|
||||
:target: https://dev.azure.com/ansible/ansible/_build/latest?definitionId=20&branchName=devel
|
||||
.. |Chat badge| image:: https://img.shields.io/badge/chat-IRC-brightgreen.svg
|
||||
:target: https://docs.ansible.com/ansible/latest/community/communication.html
|
||||
.. |Code Of Conduct| image:: https://img.shields.io/badge/code%20of%20conduct-Ansible-silver.svg
|
||||
:target: https://docs.ansible.com/ansible/latest/community/code_of_conduct.html
|
||||
:alt: Ansible Code of Conduct
|
||||
.. |Mailing Lists| image:: https://img.shields.io/badge/mailing%20lists-Ansible-orange.svg
|
||||
:target: https://docs.ansible.com/ansible/latest/community/communication.html#mailing-list-information
|
||||
:alt: Ansible mailing lists
|
||||
.. |License| image:: https://img.shields.io/badge/license-GPL%20v3.0-brightgreen.svg
|
||||
:target: COPYING
|
||||
:alt: Repository License
|
||||
.. |CII Best Practices| image:: https://bestpractices.coreinfrastructure.org/projects/2372/badge
|
||||
:target: https://bestpractices.coreinfrastructure.org/projects/2372
|
||||
:alt: Ansible CII Best Practices certification
|
||||
@ -5,6 +5,197 @@ ansible-core 2.14 "C'mon Everybody" Release Notes
|
||||
.. contents:: Topics
|
||||
|
||||
|
||||
v2.14.15
|
||||
========
|
||||
|
||||
Release Summary
|
||||
---------------
|
||||
|
||||
| Release Date: 2024-03-25
|
||||
| `Porting Guide <https://docs.ansible.com/ansible-core/2.14/porting_guides/porting_guide_core_2.14.html>`__
|
||||
|
||||
|
||||
Minor Changes
|
||||
-------------
|
||||
|
||||
- ansible-test - Add a work-around for permission denied errors when using ``pytest >= 8`` on multi-user systems with an installed version of ``ansible-test``.
|
||||
|
||||
Bugfixes
|
||||
--------
|
||||
|
||||
- Fix an issue when setting a plugin name from an unsafe source resulted in ``ValueError: unmarshallable object`` (https://github.com/ansible/ansible/issues/82708)
|
||||
- ansible-test - The ``libexpat`` package is automatically upgraded during remote bootstrapping to maintain compatibility with newer Python packages.
|
||||
|
||||
v2.14.14
|
||||
========
|
||||
|
||||
Release Summary
|
||||
---------------
|
||||
|
||||
| Release Date: 2024-01-29
|
||||
| `Porting Guide <https://docs.ansible.com/ansible-core/2.14/porting_guides/porting_guide_core_2.14.html>`__
|
||||
|
||||
|
||||
Minor Changes
|
||||
-------------
|
||||
|
||||
- ansible-test - Removed `freebsd/12.4` remote.
|
||||
|
||||
Security Fixes
|
||||
--------------
|
||||
|
||||
- ANSIBLE_NO_LOG - Address issue where ANSIBLE_NO_LOG was ignored (CVE-2024-0690)
|
||||
|
||||
Bugfixes
|
||||
--------
|
||||
|
||||
- ``ansible-test sanity --test runtime-metadata`` - add ``action_plugin`` as a valid field for modules in the schema (https://github.com/ansible/ansible/pull/82562).
|
||||
- ansible-galaxy role install - normalize tarfile paths and symlinks using ``ansible.utils.path.unfrackpath`` and consider them valid as long as the realpath is in the tarfile's role directory (https://github.com/ansible/ansible/issues/81965).
|
||||
- unsafe data - Enable directly using ``AnsibleUnsafeText`` with Python ``pathlib`` (https://github.com/ansible/ansible/issues/82414)
|
||||
|
||||
v2.14.13
|
||||
========
|
||||
|
||||
Release Summary
|
||||
---------------
|
||||
|
||||
| Release Date: 2023-12-11
|
||||
| `Porting Guide <https://docs.ansible.com/ansible-core/2.14/porting_guides/porting_guide_core_2.14.html>`__
|
||||
|
||||
|
||||
Minor Changes
|
||||
-------------
|
||||
|
||||
- ansible-test - Add FreeBSD 13.2 remote.
|
||||
- ansible-test - Removed `freebsd/13.1` remote.
|
||||
|
||||
Bugfixes
|
||||
--------
|
||||
|
||||
- unsafe data - Address an incompatibility when iterating or getting a single index from ``AnsibleUnsafeBytes``
|
||||
- unsafe data - Address an incompatibility with ``AnsibleUnsafeText`` and ``AnsibleUnsafeBytes`` when pickling with ``protocol=0``
|
||||
|
||||
v2.14.12
|
||||
========
|
||||
|
||||
Release Summary
|
||||
---------------
|
||||
|
||||
| Release Date: 2023-12-04
|
||||
| `Porting Guide <https://docs.ansible.com/ansible-core/2.14/porting_guides/porting_guide_core_2.14.html>`__
|
||||
|
||||
|
||||
Minor Changes
|
||||
-------------
|
||||
|
||||
- ansible-test - Windows 2012 and 2012-R2 instances are now requested from Azure instead of AWS.
|
||||
|
||||
Breaking Changes / Porting Guide
|
||||
--------------------------------
|
||||
|
||||
- assert - Nested templating may result in an inability for the conditional to be evaluated. See the porting guide for more information.
|
||||
|
||||
Security Fixes
|
||||
--------------
|
||||
|
||||
- templating - Address issues where internal templating can cause unsafe variables to lose their unsafe designation (CVE-2023-5764)
|
||||
|
||||
Bugfixes
|
||||
--------
|
||||
|
||||
- ansible-pull now will expand relative paths for the ``-d|--directory`` option is now expanded before use.
|
||||
- ansible-test - Fix parsing of cgroup entries which contain a ``:`` in the path (https://github.com/ansible/ansible/issues/81977).
|
||||
|
||||
v2.14.11
|
||||
========
|
||||
|
||||
Release Summary
|
||||
---------------
|
||||
|
||||
| Release Date: 2023-10-09
|
||||
| `Porting Guide <https://docs.ansible.com/ansible-core/2.14/porting_guides/porting_guide_core_2.14.html>`__
|
||||
|
||||
|
||||
Minor Changes
|
||||
-------------
|
||||
|
||||
- ansible-galaxy dependency resolution messages have changed the unexplained 'virtual' collection for the specific type ('scm', 'dir', etc) that is more user friendly
|
||||
|
||||
Security Fixes
|
||||
--------------
|
||||
|
||||
- ansible-galaxy - Prevent roles from using symlinks to overwrite files outside of the installation directory (CVE-2023-5115)
|
||||
|
||||
Bugfixes
|
||||
--------
|
||||
|
||||
- PluginLoader - fix Jinja plugin performance issues (https://github.com/ansible/ansible/issues/79652)
|
||||
- ansible-galaxy error on dependency resolution will not error itself due to 'virtual' collections not having a name/namespace.
|
||||
- ansible-galaxy info - fix reporting no role found when lookup_role_by_name returns None.
|
||||
- winrm - Better handle send input failures when communicating with hosts under load
|
||||
|
||||
v2.14.10
|
||||
========
|
||||
|
||||
Release Summary
|
||||
---------------
|
||||
|
||||
| Release Date: 2023-09-11
|
||||
| `Porting Guide <https://docs.ansible.com/ansible-core/2.14/porting_guides/porting_guide_core_2.14.html>`__
|
||||
|
||||
|
||||
Minor Changes
|
||||
-------------
|
||||
|
||||
- ansible-test — Replaced `freebsd/12.3` remote with `freebsd/12.4`. The former is no longer functional.
|
||||
|
||||
Bugfixes
|
||||
--------
|
||||
|
||||
- PowerShell - Remove some code which is no longer valid for dotnet 5+
|
||||
- ansible-galaxy - Enabled the ``data`` tarfile filter during role installation for Python versions that support it. A probing mechanism is used to avoid Python versions with a broken implementation.
|
||||
- ansible-test - Always use ansible-test managed entry points for ansible-core CLI tools when not running from source. This fixes issues where CLI entry points created during install are not compatible with ansible-test.
|
||||
- tarfile - handle data filter deprecation warning message for extract and extractall (https://github.com/ansible/ansible/issues/80832).
|
||||
|
||||
v2.14.9
|
||||
=======
|
||||
|
||||
Release Summary
|
||||
---------------
|
||||
|
||||
| Release Date: 2023-08-14
|
||||
| `Porting Guide <https://docs.ansible.com/ansible-core/2.14/porting_guides/porting_guide_core_2.14.html>`__
|
||||
|
||||
|
||||
Minor Changes
|
||||
-------------
|
||||
|
||||
- Removed ``exclude`` and ``recursive-exclude`` commands for generated files from the ``MANIFEST.in`` file. These excludes were unnecessary since releases are expected to be built with a clean worktree.
|
||||
- Removed ``exclude`` commands for sanity test files from the ``MANIFEST.in`` file. These tests were previously excluded because they did not pass when run from an sdist. However, sanity tests are not expected to pass from an sdist, so excluding some (but not all) of the failing tests makes little sense.
|
||||
- Removed redundant ``include`` commands from the ``MANIFEST.in`` file. These includes either duplicated default behavior or another command.
|
||||
- The ``ansible-core`` sdist no longer contains pre-generated man pages. Instead, a ``packaging/cli-doc/build.py`` script is included in the sdist. This script can generate man pages and standalone RST documentation for ``ansible-core`` CLI programs.
|
||||
- The ``docs`` and ``examples`` directories are no longer included in the ``ansible-core`` sdist. These directories have been moved to the https://github.com/ansible/ansible-documentation repository.
|
||||
- The minimum required ``setuptools`` version is now 45.2.0, as it is the oldest version to support Python 3.10.
|
||||
- Use ``include`` where ``recursive-include`` is unnecessary in the ``MANIFEST.in`` file.
|
||||
- Use ``package_data`` instead of ``include_package_data`` for ``setup.cfg`` to avoid ``setuptools`` warnings.
|
||||
- ansible-test - Update the logic used to detect when ``ansible-test`` is running from source.
|
||||
|
||||
Bugfixes
|
||||
--------
|
||||
|
||||
- Exclude internal options from man pages and docs.
|
||||
- Fix ``ansible-config init`` man page option indentation.
|
||||
- The ``ansible-config init`` command now has a documentation description.
|
||||
- The ``ansible-galaxy collection download`` command now has a documentation description.
|
||||
- The ``ansible-galaxy collection install`` command documentation is now visible (previously hidden by a decorator).
|
||||
- The ``ansible-galaxy collection verify`` command now has a documentation description.
|
||||
- The ``ansible-galaxy role install`` command documentation is now visible (previously hidden by a decorator).
|
||||
- The ``ansible-inventory`` command command now has a documentation description (previously used as the epilog).
|
||||
- Update module_utils.urls unit test to work with cryptography >= 41.0.0.
|
||||
- When generating man pages, use ``func`` to find the command function instead of looking it up by the command name.
|
||||
- ansible-test - Pre-build a PyYAML wheel before installing requirements to avoid a potential Cython build failure.
|
||||
- man page build - Sub commands of ``ansible-galaxy role`` and ``ansible-galaxy collection`` are now documented.
|
||||
|
||||
v2.14.8
|
||||
=======
|
||||
|
||||
|
||||
@ -1,6 +0,0 @@
|
||||
Placeholder changelog
|
||||
=====================
|
||||
|
||||
This file is a placeholder; a version-specific ``CHANGELOG-vX.Y.rst`` will be generated during releases from fragments
|
||||
under changelogs/fragments. On release branches once a release has been created, consult the branch's version-specific
|
||||
file for changes that have occurred in that branch.
|
||||
8
changelogs/README.md
Normal file
8
changelogs/README.md
Normal file
@ -0,0 +1,8 @@
|
||||
Changelogs
|
||||
==========
|
||||
|
||||
As part of the release process a version-specific `CHANGELOG-vX.Y.rst` will be generated from fragments in
|
||||
the `fragments` directory.
|
||||
|
||||
On release branches once a release has been created, consult the branch's version-specific file for changes that have
|
||||
occurred in that branch. The `devel` branch does not have a generated changelog, only changelog fragments.
|
||||
@ -857,6 +857,222 @@ releases:
|
||||
- fork_safe_stdio.yml
|
||||
- v2.14.1_summary.yaml
|
||||
release_date: '2022-12-06'
|
||||
2.14.10:
|
||||
changes:
|
||||
release_summary: '| Release Date: 2023-09-11
|
||||
|
||||
| `Porting Guide <https://docs.ansible.com/ansible-core/2.14/porting_guides/porting_guide_core_2.14.html>`__
|
||||
|
||||
'
|
||||
codename: C'mon Everybody
|
||||
fragments:
|
||||
- 2.14.10_summary.yaml
|
||||
release_date: '2023-09-11'
|
||||
2.14.10rc1:
|
||||
changes:
|
||||
bugfixes:
|
||||
- PowerShell - Remove some code which is no longer valid for dotnet 5+
|
||||
- ansible-galaxy - Enabled the ``data`` tarfile filter during role installation
|
||||
for Python versions that support it. A probing mechanism is used to avoid
|
||||
Python versions with a broken implementation.
|
||||
- ansible-test - Always use ansible-test managed entry points for ansible-core
|
||||
CLI tools when not running from source. This fixes issues where CLI entry
|
||||
points created during install are not compatible with ansible-test.
|
||||
- tarfile - handle data filter deprecation warning message for extract and extractall
|
||||
(https://github.com/ansible/ansible/issues/80832).
|
||||
minor_changes:
|
||||
- "ansible-test \u2014 Replaced `freebsd/12.3` remote with `freebsd/12.4`. The
|
||||
former is no longer functional."
|
||||
release_summary: '| Release Date: 2023-09-05
|
||||
|
||||
| `Porting Guide <https://docs.ansible.com/ansible-core/2.14/porting_guides/porting_guide_core_2.14.html>`__
|
||||
|
||||
'
|
||||
codename: C'mon Everybody
|
||||
fragments:
|
||||
- 2.14.10rc1_summary.yaml
|
||||
- ansible-test-entry-points.yml
|
||||
- dotnet-preparation.yml
|
||||
- freebsd-12.3-replacement.yml
|
||||
- tarfile_extract_warn.yml
|
||||
release_date: '2023-09-05'
|
||||
2.14.11:
|
||||
changes:
|
||||
release_summary: '| Release Date: 2023-10-09
|
||||
|
||||
| `Porting Guide <https://docs.ansible.com/ansible-core/2.14/porting_guides/porting_guide_core_2.14.html>`__
|
||||
|
||||
'
|
||||
codename: C'mon Everybody
|
||||
fragments:
|
||||
- 2.14.11_summary.yaml
|
||||
release_date: '2023-10-09'
|
||||
2.14.11rc1:
|
||||
changes:
|
||||
bugfixes:
|
||||
- PluginLoader - fix Jinja plugin performance issues (https://github.com/ansible/ansible/issues/79652)
|
||||
- ansible-galaxy error on dependency resolution will not error itself due to
|
||||
'virtual' collections not having a name/namespace.
|
||||
- ansible-galaxy info - fix reporting no role found when lookup_role_by_name
|
||||
returns None.
|
||||
- winrm - Better handle send input failures when communicating with hosts under
|
||||
load
|
||||
minor_changes:
|
||||
- ansible-galaxy dependency resolution messages have changed the unexplained
|
||||
'virtual' collection for the specific type ('scm', 'dir', etc) that is more
|
||||
user friendly
|
||||
release_summary: '| Release Date: 2023-10-03
|
||||
|
||||
| `Porting Guide <https://docs.ansible.com/ansible-core/2.14/porting_guides/porting_guide_core_2.14.html>`__
|
||||
|
||||
'
|
||||
security_fixes:
|
||||
- ansible-galaxy - Prevent roles from using symlinks to overwrite files outside
|
||||
of the installation directory (CVE-2023-5115)
|
||||
codename: C'mon Everybody
|
||||
fragments:
|
||||
- 2.14.11rc1_summary.yaml
|
||||
- cve-2023-5115.yml
|
||||
- fix-ansible-galaxy-info-no-role-found.yml
|
||||
- galaxy_dep_res_msgs.yml
|
||||
- jinja_plugin_cache_cleanup.yml
|
||||
- winrm-send-input.yml
|
||||
release_date: '2023-10-03'
|
||||
2.14.12:
|
||||
changes:
|
||||
release_summary: '| Release Date: 2023-12-04
|
||||
|
||||
| `Porting Guide <https://docs.ansible.com/ansible-core/2.14/porting_guides/porting_guide_core_2.14.html>`__
|
||||
|
||||
'
|
||||
codename: C'mon Everybody
|
||||
fragments:
|
||||
- 2.14.12_summary.yaml
|
||||
release_date: '2023-12-04'
|
||||
2.14.12rc1:
|
||||
changes:
|
||||
breaking_changes:
|
||||
- assert - Nested templating may result in an inability for the conditional
|
||||
to be evaluated. See the porting guide for more information.
|
||||
bugfixes:
|
||||
- ansible-pull now will expand relative paths for the ``-d|--directory`` option
|
||||
is now expanded before use.
|
||||
- ansible-test - Fix parsing of cgroup entries which contain a ``:`` in the
|
||||
path (https://github.com/ansible/ansible/issues/81977).
|
||||
minor_changes:
|
||||
- ansible-test - Windows 2012 and 2012-R2 instances are now requested from Azure
|
||||
instead of AWS.
|
||||
release_summary: '| Release Date: 2023-11-27
|
||||
|
||||
| `Porting Guide <https://docs.ansible.com/ansible-core/2.14/porting_guides/porting_guide_core_2.14.html>`__
|
||||
|
||||
'
|
||||
security_fixes:
|
||||
- templating - Address issues where internal templating can cause unsafe variables
|
||||
to lose their unsafe designation (CVE-2023-5764)
|
||||
codename: C'mon Everybody
|
||||
fragments:
|
||||
- 2.14.12rc1_summary.yaml
|
||||
- ansible-test-cgroup-split.yml
|
||||
- ansible-test-windows-2012-and-2012-R2.yml
|
||||
- cve-2023-5764.yml
|
||||
- pull_unfrack_dest.yml
|
||||
release_date: '2023-11-27'
|
||||
2.14.13:
|
||||
changes:
|
||||
bugfixes:
|
||||
- unsafe data - Address an incompatibility when iterating or getting a single
|
||||
index from ``AnsibleUnsafeBytes``
|
||||
- unsafe data - Address an incompatibility with ``AnsibleUnsafeText`` and ``AnsibleUnsafeBytes``
|
||||
when pickling with ``protocol=0``
|
||||
minor_changes:
|
||||
- ansible-test - Add FreeBSD 13.2 remote.
|
||||
- ansible-test - Removed `freebsd/13.1` remote.
|
||||
release_summary: '| Release Date: 2023-12-11
|
||||
|
||||
| `Porting Guide <https://docs.ansible.com/ansible-core/2.14/porting_guides/porting_guide_core_2.14.html>`__
|
||||
|
||||
'
|
||||
codename: C'mon Everybody
|
||||
fragments:
|
||||
- 2.14.13_summary.yaml
|
||||
- ci_freebsd_new.yml
|
||||
- fbsd13_1_remove.yml
|
||||
- unsafe-fixes-2.yml
|
||||
release_date: '2023-12-11'
|
||||
2.14.14:
|
||||
changes:
|
||||
release_summary: '| Release Date: 2024-01-29
|
||||
|
||||
| `Porting Guide <https://docs.ansible.com/ansible-core/2.14/porting_guides/porting_guide_core_2.14.html>`__
|
||||
|
||||
'
|
||||
codename: C'mon Everybody
|
||||
fragments:
|
||||
- 2.14.14_summary.yaml
|
||||
release_date: '2024-01-29'
|
||||
2.14.14rc1:
|
||||
changes:
|
||||
bugfixes:
|
||||
- '``ansible-test sanity --test runtime-metadata`` - add ``action_plugin`` as
|
||||
a valid field for modules in the schema (https://github.com/ansible/ansible/pull/82562).'
|
||||
- ansible-galaxy role install - normalize tarfile paths and symlinks using ``ansible.utils.path.unfrackpath``
|
||||
and consider them valid as long as the realpath is in the tarfile's role directory
|
||||
(https://github.com/ansible/ansible/issues/81965).
|
||||
- unsafe data - Enable directly using ``AnsibleUnsafeText`` with Python ``pathlib``
|
||||
(https://github.com/ansible/ansible/issues/82414)
|
||||
minor_changes:
|
||||
- ansible-test - Removed `freebsd/12.4` remote.
|
||||
release_summary: '| Release Date: 2024-01-22
|
||||
|
||||
| `Porting Guide <https://docs.ansible.com/ansible-core/2.14/porting_guides/porting_guide_core_2.14.html>`__
|
||||
|
||||
'
|
||||
security_fixes:
|
||||
- ANSIBLE_NO_LOG - Address issue where ANSIBLE_NO_LOG was ignored (CVE-2024-0690)
|
||||
codename: C'mon Everybody
|
||||
fragments:
|
||||
- 2.14.14rc1_summary.yaml
|
||||
- ansible-galaxy-role-install-symlink.yml
|
||||
- cve-2024-0690.yml
|
||||
- fix-runtime-metadata-modules-action_plugin.yml
|
||||
- freebsd_12_4_removal.yml
|
||||
- unsafe-intern.yml
|
||||
release_date: '2024-01-22'
|
||||
2.14.15:
|
||||
changes:
|
||||
bugfixes:
|
||||
- ansible-test - The ``libexpat`` package is automatically upgraded during remote
|
||||
bootstrapping to maintain compatibility with newer Python packages.
|
||||
release_summary: '| Release Date: 2024-03-25
|
||||
|
||||
| `Porting Guide <https://docs.ansible.com/ansible-core/2.14/porting_guides/porting_guide_core_2.14.html>`__
|
||||
|
||||
'
|
||||
codename: C'mon Everybody
|
||||
fragments:
|
||||
- 2.14.15_summary.yaml
|
||||
- ansible-test-alpine-libexpat.yml
|
||||
release_date: '2024-03-25'
|
||||
2.14.15rc1:
|
||||
changes:
|
||||
bugfixes:
|
||||
- 'Fix an issue when setting a plugin name from an unsafe source resulted in
|
||||
``ValueError: unmarshallable object`` (https://github.com/ansible/ansible/issues/82708)'
|
||||
minor_changes:
|
||||
- ansible-test - Add a work-around for permission denied errors when using ``pytest
|
||||
>= 8`` on multi-user systems with an installed version of ``ansible-test``.
|
||||
release_summary: '| Release Date: 2024-03-18
|
||||
|
||||
| `Porting Guide <https://docs.ansible.com/ansible-core/2.14/porting_guides/porting_guide_core_2.14.html>`__
|
||||
|
||||
'
|
||||
codename: C'mon Everybody
|
||||
fragments:
|
||||
- 2.14.15rc1_summary.yaml
|
||||
- 82708-unsafe-plugin-name-error.yml
|
||||
- ansible-test-pytest-8.yml
|
||||
release_date: '2024-03-18'
|
||||
2.14.1rc1:
|
||||
changes:
|
||||
bugfixes:
|
||||
@ -1376,3 +1592,82 @@ releases:
|
||||
- long-collection-paths-fix.yml
|
||||
- no-stacked-descriptors.yaml
|
||||
release_date: '2023-07-10'
|
||||
2.14.9:
|
||||
changes:
|
||||
release_summary: '| Release Date: 2023-08-14
|
||||
|
||||
| `Porting Guide <https://docs.ansible.com/ansible-core/2.14/porting_guides/porting_guide_core_2.14.html>`__
|
||||
|
||||
'
|
||||
codename: C'mon Everybody
|
||||
fragments:
|
||||
- 2.14.9_summary.yaml
|
||||
release_date: '2023-08-14'
|
||||
2.14.9rc1:
|
||||
changes:
|
||||
bugfixes:
|
||||
- Exclude internal options from man pages and docs.
|
||||
- Fix ``ansible-config init`` man page option indentation.
|
||||
- The ``ansible-config init`` command now has a documentation description.
|
||||
- The ``ansible-galaxy collection download`` command now has a documentation
|
||||
description.
|
||||
- The ``ansible-galaxy collection install`` command documentation is now visible
|
||||
(previously hidden by a decorator).
|
||||
- The ``ansible-galaxy collection verify`` command now has a documentation description.
|
||||
- The ``ansible-galaxy role install`` command documentation is now visible (previously
|
||||
hidden by a decorator).
|
||||
- The ``ansible-inventory`` command command now has a documentation description
|
||||
(previously used as the epilog).
|
||||
- Update module_utils.urls unit test to work with cryptography >= 41.0.0.
|
||||
- When generating man pages, use ``func`` to find the command function instead
|
||||
of looking it up by the command name.
|
||||
- ansible-test - Pre-build a PyYAML wheel before installing requirements to
|
||||
avoid a potential Cython build failure.
|
||||
- man page build - Sub commands of ``ansible-galaxy role`` and ``ansible-galaxy
|
||||
collection`` are now documented.
|
||||
minor_changes:
|
||||
- Removed ``exclude`` and ``recursive-exclude`` commands for generated files
|
||||
from the ``MANIFEST.in`` file. These excludes were unnecessary since releases
|
||||
are expected to be built with a clean worktree.
|
||||
- Removed ``exclude`` commands for sanity test files from the ``MANIFEST.in``
|
||||
file. These tests were previously excluded because they did not pass when
|
||||
run from an sdist. However, sanity tests are not expected to pass from an
|
||||
sdist, so excluding some (but not all) of the failing tests makes little sense.
|
||||
- Removed redundant ``include`` commands from the ``MANIFEST.in`` file. These
|
||||
includes either duplicated default behavior or another command.
|
||||
- The ``ansible-core`` sdist no longer contains pre-generated man pages. Instead,
|
||||
a ``packaging/cli-doc/build.py`` script is included in the sdist. This script
|
||||
can generate man pages and standalone RST documentation for ``ansible-core``
|
||||
CLI programs.
|
||||
- The ``docs`` and ``examples`` directories are no longer included in the ``ansible-core``
|
||||
sdist. These directories have been moved to the https://github.com/ansible/ansible-documentation
|
||||
repository.
|
||||
- The minimum required ``setuptools`` version is now 45.2.0, as it is the oldest
|
||||
version to support Python 3.10.
|
||||
- Use ``include`` where ``recursive-include`` is unnecessary in the ``MANIFEST.in``
|
||||
file.
|
||||
- Use ``package_data`` instead of ``include_package_data`` for ``setup.cfg``
|
||||
to avoid ``setuptools`` warnings.
|
||||
- ansible-test - Update the logic used to detect when ``ansible-test`` is running
|
||||
from source.
|
||||
release_summary: '| Release Date: 2023-08-07
|
||||
|
||||
| `Porting Guide <https://docs.ansible.com/ansible-core/2.14/porting_guides/porting_guide_core_2.14.html>`__
|
||||
|
||||
'
|
||||
codename: C'mon Everybody
|
||||
fragments:
|
||||
- 2.14.9rc1_summary.yaml
|
||||
- add-missing-cli-docs.yml
|
||||
- ansible-test-layout-detection.yml
|
||||
- ansible-test-minimum-setuptools.yml
|
||||
- ansible-test-pyyaml-build.yml
|
||||
- fix-setuptools-warnings.yml
|
||||
- man-page-subcommands.yml
|
||||
- manifest-in-cleanup.yml
|
||||
- missing-doc-func.yml
|
||||
- omit-man-pages-from-sdist.yml
|
||||
- remove-docs-examples.yml
|
||||
- suppressed-options.yml
|
||||
- urls-unit-test-latest-cryptography.yml
|
||||
release_date: '2023-08-07'
|
||||
|
||||
3
changelogs/fragments/2.14.10_summary.yaml
Normal file
3
changelogs/fragments/2.14.10_summary.yaml
Normal file
@ -0,0 +1,3 @@
|
||||
release_summary: |
|
||||
| Release Date: 2023-09-11
|
||||
| `Porting Guide <https://docs.ansible.com/ansible-core/2.14/porting_guides/porting_guide_core_2.14.html>`__
|
||||
3
changelogs/fragments/2.14.10rc1_summary.yaml
Normal file
3
changelogs/fragments/2.14.10rc1_summary.yaml
Normal file
@ -0,0 +1,3 @@
|
||||
release_summary: |
|
||||
| Release Date: 2023-09-05
|
||||
| `Porting Guide <https://docs.ansible.com/ansible-core/2.14/porting_guides/porting_guide_core_2.14.html>`__
|
||||
3
changelogs/fragments/2.14.11_summary.yaml
Normal file
3
changelogs/fragments/2.14.11_summary.yaml
Normal file
@ -0,0 +1,3 @@
|
||||
release_summary: |
|
||||
| Release Date: 2023-10-09
|
||||
| `Porting Guide <https://docs.ansible.com/ansible-core/2.14/porting_guides/porting_guide_core_2.14.html>`__
|
||||
3
changelogs/fragments/2.14.11rc1_summary.yaml
Normal file
3
changelogs/fragments/2.14.11rc1_summary.yaml
Normal file
@ -0,0 +1,3 @@
|
||||
release_summary: |
|
||||
| Release Date: 2023-10-03
|
||||
| `Porting Guide <https://docs.ansible.com/ansible-core/2.14/porting_guides/porting_guide_core_2.14.html>`__
|
||||
3
changelogs/fragments/2.14.12_summary.yaml
Normal file
3
changelogs/fragments/2.14.12_summary.yaml
Normal file
@ -0,0 +1,3 @@
|
||||
release_summary: |
|
||||
| Release Date: 2023-12-04
|
||||
| `Porting Guide <https://docs.ansible.com/ansible-core/2.14/porting_guides/porting_guide_core_2.14.html>`__
|
||||
3
changelogs/fragments/2.14.12rc1_summary.yaml
Normal file
3
changelogs/fragments/2.14.12rc1_summary.yaml
Normal file
@ -0,0 +1,3 @@
|
||||
release_summary: |
|
||||
| Release Date: 2023-11-27
|
||||
| `Porting Guide <https://docs.ansible.com/ansible-core/2.14/porting_guides/porting_guide_core_2.14.html>`__
|
||||
3
changelogs/fragments/2.14.13_summary.yaml
Normal file
3
changelogs/fragments/2.14.13_summary.yaml
Normal file
@ -0,0 +1,3 @@
|
||||
release_summary: |
|
||||
| Release Date: 2023-12-11
|
||||
| `Porting Guide <https://docs.ansible.com/ansible-core/2.14/porting_guides/porting_guide_core_2.14.html>`__
|
||||
3
changelogs/fragments/2.14.14_summary.yaml
Normal file
3
changelogs/fragments/2.14.14_summary.yaml
Normal file
@ -0,0 +1,3 @@
|
||||
release_summary: |
|
||||
| Release Date: 2024-01-29
|
||||
| `Porting Guide <https://docs.ansible.com/ansible-core/2.14/porting_guides/porting_guide_core_2.14.html>`__
|
||||
3
changelogs/fragments/2.14.14rc1_summary.yaml
Normal file
3
changelogs/fragments/2.14.14rc1_summary.yaml
Normal file
@ -0,0 +1,3 @@
|
||||
release_summary: |
|
||||
| Release Date: 2024-01-22
|
||||
| `Porting Guide <https://docs.ansible.com/ansible-core/2.14/porting_guides/porting_guide_core_2.14.html>`__
|
||||
3
changelogs/fragments/2.14.15_summary.yaml
Normal file
3
changelogs/fragments/2.14.15_summary.yaml
Normal file
@ -0,0 +1,3 @@
|
||||
release_summary: |
|
||||
| Release Date: 2024-03-25
|
||||
| `Porting Guide <https://docs.ansible.com/ansible-core/2.14/porting_guides/porting_guide_core_2.14.html>`__
|
||||
3
changelogs/fragments/2.14.15rc1_summary.yaml
Normal file
3
changelogs/fragments/2.14.15rc1_summary.yaml
Normal file
@ -0,0 +1,3 @@
|
||||
release_summary: |
|
||||
| Release Date: 2024-03-18
|
||||
| `Porting Guide <https://docs.ansible.com/ansible-core/2.14/porting_guides/porting_guide_core_2.14.html>`__
|
||||
3
changelogs/fragments/2.14.9_summary.yaml
Normal file
3
changelogs/fragments/2.14.9_summary.yaml
Normal file
@ -0,0 +1,3 @@
|
||||
release_summary: |
|
||||
| Release Date: 2023-08-14
|
||||
| `Porting Guide <https://docs.ansible.com/ansible-core/2.14/porting_guides/porting_guide_core_2.14.html>`__
|
||||
3
changelogs/fragments/2.14.9rc1_summary.yaml
Normal file
3
changelogs/fragments/2.14.9rc1_summary.yaml
Normal file
@ -0,0 +1,3 @@
|
||||
release_summary: |
|
||||
| Release Date: 2023-08-07
|
||||
| `Porting Guide <https://docs.ansible.com/ansible-core/2.14/porting_guides/porting_guide_core_2.14.html>`__
|
||||
2
changelogs/fragments/82708-unsafe-plugin-name-error.yml
Normal file
2
changelogs/fragments/82708-unsafe-plugin-name-error.yml
Normal file
@ -0,0 +1,2 @@
|
||||
bugfixes:
|
||||
- "Fix an issue when setting a plugin name from an unsafe source resulted in ``ValueError: unmarshallable object`` (https://github.com/ansible/ansible/issues/82708)"
|
||||
8
changelogs/fragments/add-missing-cli-docs.yml
Normal file
8
changelogs/fragments/add-missing-cli-docs.yml
Normal file
@ -0,0 +1,8 @@
|
||||
bugfixes:
|
||||
- The ``ansible-config init`` command now has a documentation description.
|
||||
- The ``ansible-galaxy collection download`` command now has a documentation description.
|
||||
- The ``ansible-galaxy collection verify`` command now has a documentation description.
|
||||
- The ``ansible-inventory`` command command now has a documentation description (previously used as the epilog).
|
||||
- The ``ansible-galaxy collection install`` command documentation is now visible (previously hidden by a decorator).
|
||||
- The ``ansible-galaxy role install`` command documentation is now visible (previously hidden by a decorator).
|
||||
- Fix ``ansible-config init`` man page option indentation.
|
||||
@ -0,0 +1,2 @@
|
||||
bugfixes:
|
||||
- ansible-galaxy role install - normalize tarfile paths and symlinks using ``ansible.utils.path.unfrackpath`` and consider them valid as long as the realpath is in the tarfile's role directory (https://github.com/ansible/ansible/issues/81965).
|
||||
2
changelogs/fragments/ansible-test-alpine-libexpat.yml
Normal file
2
changelogs/fragments/ansible-test-alpine-libexpat.yml
Normal file
@ -0,0 +1,2 @@
|
||||
bugfixes:
|
||||
- ansible-test - The ``libexpat`` package is automatically upgraded during remote bootstrapping to maintain compatibility with newer Python packages.
|
||||
2
changelogs/fragments/ansible-test-cgroup-split.yml
Normal file
2
changelogs/fragments/ansible-test-cgroup-split.yml
Normal file
@ -0,0 +1,2 @@
|
||||
bugfixes:
|
||||
- ansible-test - Fix parsing of cgroup entries which contain a ``:`` in the path (https://github.com/ansible/ansible/issues/81977).
|
||||
3
changelogs/fragments/ansible-test-entry-points.yml
Normal file
3
changelogs/fragments/ansible-test-entry-points.yml
Normal file
@ -0,0 +1,3 @@
|
||||
bugfixes:
|
||||
- ansible-test - Always use ansible-test managed entry points for ansible-core CLI tools when not running from source.
|
||||
This fixes issues where CLI entry points created during install are not compatible with ansible-test.
|
||||
2
changelogs/fragments/ansible-test-layout-detection.yml
Normal file
2
changelogs/fragments/ansible-test-layout-detection.yml
Normal file
@ -0,0 +1,2 @@
|
||||
minor_changes:
|
||||
- ansible-test - Update the logic used to detect when ``ansible-test`` is running from source.
|
||||
2
changelogs/fragments/ansible-test-minimum-setuptools.yml
Normal file
2
changelogs/fragments/ansible-test-minimum-setuptools.yml
Normal file
@ -0,0 +1,2 @@
|
||||
minor_changes:
|
||||
- The minimum required ``setuptools`` version is now 45.2.0, as it is the oldest version to support Python 3.10.
|
||||
2
changelogs/fragments/ansible-test-pytest-8.yml
Normal file
2
changelogs/fragments/ansible-test-pytest-8.yml
Normal file
@ -0,0 +1,2 @@
|
||||
minor_changes:
|
||||
- ansible-test - Add a work-around for permission denied errors when using ``pytest >= 8`` on multi-user systems with an installed version of ``ansible-test``.
|
||||
2
changelogs/fragments/ansible-test-pyyaml-build.yml
Normal file
2
changelogs/fragments/ansible-test-pyyaml-build.yml
Normal file
@ -0,0 +1,2 @@
|
||||
bugfixes:
|
||||
- ansible-test - Pre-build a PyYAML wheel before installing requirements to avoid a potential Cython build failure.
|
||||
@ -0,0 +1,2 @@
|
||||
minor_changes:
|
||||
- ansible-test - Windows 2012 and 2012-R2 instances are now requested from Azure instead of AWS.
|
||||
2
changelogs/fragments/ci_freebsd_new.yml
Normal file
2
changelogs/fragments/ci_freebsd_new.yml
Normal file
@ -0,0 +1,2 @@
|
||||
minor_changes:
|
||||
- ansible-test - Add FreeBSD 13.2 remote.
|
||||
3
changelogs/fragments/cve-2023-5115.yml
Normal file
3
changelogs/fragments/cve-2023-5115.yml
Normal file
@ -0,0 +1,3 @@
|
||||
security_fixes:
|
||||
- ansible-galaxy - Prevent roles from using symlinks to overwrite
|
||||
files outside of the installation directory (CVE-2023-5115)
|
||||
6
changelogs/fragments/cve-2023-5764.yml
Normal file
6
changelogs/fragments/cve-2023-5764.yml
Normal file
@ -0,0 +1,6 @@
|
||||
security_fixes:
|
||||
- templating - Address issues where internal templating can cause unsafe
|
||||
variables to lose their unsafe designation (CVE-2023-5764)
|
||||
breaking_changes:
|
||||
- assert - Nested templating may result in an inability for the conditional
|
||||
to be evaluated. See the porting guide for more information.
|
||||
2
changelogs/fragments/cve-2024-0690.yml
Normal file
2
changelogs/fragments/cve-2024-0690.yml
Normal file
@ -0,0 +1,2 @@
|
||||
security_fixes:
|
||||
- ANSIBLE_NO_LOG - Address issue where ANSIBLE_NO_LOG was ignored (CVE-2024-0690)
|
||||
2
changelogs/fragments/dotnet-preparation.yml
Normal file
2
changelogs/fragments/dotnet-preparation.yml
Normal file
@ -0,0 +1,2 @@
|
||||
bugfixes:
|
||||
- PowerShell - Remove some code which is no longer valid for dotnet 5+
|
||||
2
changelogs/fragments/fbsd13_1_remove.yml
Normal file
2
changelogs/fragments/fbsd13_1_remove.yml
Normal file
@ -0,0 +1,2 @@
|
||||
minor_changes:
|
||||
- ansible-test - Removed `freebsd/13.1` remote.
|
||||
@ -0,0 +1,2 @@
|
||||
bugfixes:
|
||||
- ansible-galaxy info - fix reporting no role found when lookup_role_by_name returns None.
|
||||
@ -0,0 +1,4 @@
|
||||
bugfixes:
|
||||
- >-
|
||||
``ansible-test sanity --test runtime-metadata`` - add ``action_plugin`` as a valid field
|
||||
for modules in the schema (https://github.com/ansible/ansible/pull/82562).
|
||||
2
changelogs/fragments/fix-setuptools-warnings.yml
Normal file
2
changelogs/fragments/fix-setuptools-warnings.yml
Normal file
@ -0,0 +1,2 @@
|
||||
minor_changes:
|
||||
- Use ``package_data`` instead of ``include_package_data`` for ``setup.cfg`` to avoid ``setuptools`` warnings.
|
||||
4
changelogs/fragments/freebsd-12.3-replacement.yml
Normal file
4
changelogs/fragments/freebsd-12.3-replacement.yml
Normal file
@ -0,0 +1,4 @@
|
||||
minor_changes:
|
||||
- >-
|
||||
ansible-test — Replaced `freebsd/12.3` remote with `freebsd/12.4`.
|
||||
The former is no longer functional.
|
||||
2
changelogs/fragments/freebsd_12_4_removal.yml
Normal file
2
changelogs/fragments/freebsd_12_4_removal.yml
Normal file
@ -0,0 +1,2 @@
|
||||
minor_changes:
|
||||
- ansible-test - Removed `freebsd/12.4` remote.
|
||||
4
changelogs/fragments/galaxy_dep_res_msgs.yml
Normal file
4
changelogs/fragments/galaxy_dep_res_msgs.yml
Normal file
@ -0,0 +1,4 @@
|
||||
minor_changes:
|
||||
- ansible-galaxy dependency resolution messages have changed the unexplained 'virtual' collection for the specific type ('scm', 'dir', etc) that is more user friendly
|
||||
bugfixes:
|
||||
- ansible-galaxy error on dependency resolution will not error itself due to 'virtual' collections not having a name/namespace.
|
||||
2
changelogs/fragments/jinja_plugin_cache_cleanup.yml
Normal file
2
changelogs/fragments/jinja_plugin_cache_cleanup.yml
Normal file
@ -0,0 +1,2 @@
|
||||
bugfixes:
|
||||
- PluginLoader - fix Jinja plugin performance issues (https://github.com/ansible/ansible/issues/79652)
|
||||
2
changelogs/fragments/man-page-subcommands.yml
Normal file
2
changelogs/fragments/man-page-subcommands.yml
Normal file
@ -0,0 +1,2 @@
|
||||
bugfixes:
|
||||
- man page build - Sub commands of ``ansible-galaxy role`` and ``ansible-galaxy collection`` are now documented.
|
||||
9
changelogs/fragments/manifest-in-cleanup.yml
Normal file
9
changelogs/fragments/manifest-in-cleanup.yml
Normal file
@ -0,0 +1,9 @@
|
||||
minor_changes:
|
||||
- Removed ``exclude`` and ``recursive-exclude`` commands for generated files from the ``MANIFEST.in`` file.
|
||||
These excludes were unnecessary since releases are expected to be built with a clean worktree.
|
||||
- Removed ``exclude`` commands for sanity test files from the ``MANIFEST.in`` file.
|
||||
These tests were previously excluded because they did not pass when run from an sdist.
|
||||
However, sanity tests are not expected to pass from an sdist, so excluding some (but not all) of the failing tests makes little sense.
|
||||
- Removed redundant ``include`` commands from the ``MANIFEST.in`` file.
|
||||
These includes either duplicated default behavior or another command.
|
||||
- Use ``include`` where ``recursive-include`` is unnecessary in the ``MANIFEST.in`` file.
|
||||
2
changelogs/fragments/missing-doc-func.yml
Normal file
2
changelogs/fragments/missing-doc-func.yml
Normal file
@ -0,0 +1,2 @@
|
||||
bugfixes:
|
||||
- When generating man pages, use ``func`` to find the command function instead of looking it up by the command name.
|
||||
4
changelogs/fragments/omit-man-pages-from-sdist.yml
Normal file
4
changelogs/fragments/omit-man-pages-from-sdist.yml
Normal file
@ -0,0 +1,4 @@
|
||||
minor_changes:
|
||||
- The ``ansible-core`` sdist no longer contains pre-generated man pages.
|
||||
Instead, a ``packaging/cli-doc/build.py`` script is included in the sdist.
|
||||
This script can generate man pages and standalone RST documentation for ``ansible-core`` CLI programs.
|
||||
2
changelogs/fragments/pull_unfrack_dest.yml
Normal file
2
changelogs/fragments/pull_unfrack_dest.yml
Normal file
@ -0,0 +1,2 @@
|
||||
bugfixes:
|
||||
- ansible-pull now will expand relative paths for the ``-d|--directory`` option is now expanded before use.
|
||||
3
changelogs/fragments/remove-docs-examples.yml
Normal file
3
changelogs/fragments/remove-docs-examples.yml
Normal file
@ -0,0 +1,3 @@
|
||||
minor_changes:
|
||||
- The ``docs`` and ``examples`` directories are no longer included in the ``ansible-core`` sdist.
|
||||
These directories have been moved to the https://github.com/ansible/ansible-documentation repository.
|
||||
2
changelogs/fragments/suppressed-options.yml
Normal file
2
changelogs/fragments/suppressed-options.yml
Normal file
@ -0,0 +1,2 @@
|
||||
bugfixes:
|
||||
- Exclude internal options from man pages and docs.
|
||||
4
changelogs/fragments/tarfile_extract_warn.yml
Normal file
4
changelogs/fragments/tarfile_extract_warn.yml
Normal file
@ -0,0 +1,4 @@
|
||||
---
|
||||
bugfixes:
|
||||
- tarfile - handle data filter deprecation warning message for extract and extractall (https://github.com/ansible/ansible/issues/80832).
|
||||
- ansible-galaxy - Enabled the ``data`` tarfile filter during role installation for Python versions that support it. A probing mechanism is used to avoid Python versions with a broken implementation.
|
||||
3
changelogs/fragments/unsafe-fixes-2.yml
Normal file
3
changelogs/fragments/unsafe-fixes-2.yml
Normal file
@ -0,0 +1,3 @@
|
||||
bugfixes:
|
||||
- unsafe data - Address an incompatibility with ``AnsibleUnsafeText`` and ``AnsibleUnsafeBytes`` when pickling with ``protocol=0``
|
||||
- unsafe data - Address an incompatibility when iterating or getting a single index from ``AnsibleUnsafeBytes``
|
||||
3
changelogs/fragments/unsafe-intern.yml
Normal file
3
changelogs/fragments/unsafe-intern.yml
Normal file
@ -0,0 +1,3 @@
|
||||
bugfixes:
|
||||
- unsafe data - Enable directly using ``AnsibleUnsafeText`` with Python ``pathlib``
|
||||
(https://github.com/ansible/ansible/issues/82414)
|
||||
@ -0,0 +1,2 @@
|
||||
bugfixes:
|
||||
- Update module_utils.urls unit test to work with cryptography >= 41.0.0.
|
||||
2
changelogs/fragments/winrm-send-input.yml
Normal file
2
changelogs/fragments/winrm-send-input.yml
Normal file
@ -0,0 +1,2 @@
|
||||
bugfixes:
|
||||
- winrm - Better handle send input failures when communicating with hosts under load
|
||||
@ -1,85 +0,0 @@
|
||||
#!/usr/bin/env python
|
||||
|
||||
# To run this script, first make webdocs in the toplevel of the checkout. This will generate all
|
||||
# rst files from their sources. Then run this script ./docs/bin/find-plugin-refs.py
|
||||
#
|
||||
# No output means that there are no longer any bare module and plugin names referenced via :ref:
|
||||
#
|
||||
# For my listing of what needs to be changed after running this script, see the comment at the end
|
||||
# of the file
|
||||
|
||||
from __future__ import (absolute_import, division, print_function)
|
||||
__metaclass__ = type
|
||||
|
||||
import glob
|
||||
import os
|
||||
import re
|
||||
|
||||
from ansible.module_utils._text import to_text
|
||||
|
||||
|
||||
TOPDIR = os.path.join(os.path.dirname(__file__), '..', 'docsite', 'rst')
|
||||
|
||||
|
||||
def plugin_names(topdir):
|
||||
plugins = set()
|
||||
|
||||
# Modules are in a separate directory
|
||||
for module_filename in glob.glob(os.path.join(topdir, 'modules', '*_module.rst')):
|
||||
module_filename = os.path.basename(module_filename)
|
||||
module_name = module_filename[:module_filename.index('_module.rst')]
|
||||
plugins.add(module_name)
|
||||
|
||||
for plugin_filename in glob.glob(os.path.join(topdir, 'plugins', '*', '*.rst')):
|
||||
plugin_filename = os.path.basename(plugin_filename)
|
||||
plugin_name = plugin_filename[:plugin_filename.index('.rst')]
|
||||
plugins.add(plugin_name)
|
||||
|
||||
return plugins
|
||||
|
||||
|
||||
def process_refs(topdir, plugin_names):
|
||||
REF_RE = re.compile(':ref:`([^`]*)`')
|
||||
LABEL_RE = re.compile('<([^>]*)>$')
|
||||
|
||||
# Walk the whole docs tree looking for :ref:. Anywhere those are found, search for `([^`]*)`
|
||||
for dirpath, dirnames, filenames in os.walk(topdir):
|
||||
for filename in filenames:
|
||||
with open(os.path.join(dirpath, filename), 'rb') as f:
|
||||
data = f.read()
|
||||
data = to_text(data)
|
||||
for ref_match in re.finditer(REF_RE, data):
|
||||
label = ref_match.group(1)
|
||||
|
||||
# If the ref label includes "<", then search for the label inside of the "<>"
|
||||
label_match = re.search(LABEL_RE, label)
|
||||
if label_match:
|
||||
label = label_match.group(1)
|
||||
|
||||
# If the ref label is listed in plugins, then print that the file contains an unported ref
|
||||
if label in plugin_names:
|
||||
print(':ref:`{0}` matching plugin {1} was found in {2}'.format(ref_match.group(1), label, os.path.join(dirpath, filename)))
|
||||
|
||||
|
||||
if __name__ == '__main__':
|
||||
|
||||
plugins = plugin_names(TOPDIR)
|
||||
|
||||
process_refs(TOPDIR, plugins)
|
||||
|
||||
# Fixes needed: docs/bin/plugin_formatter.py
|
||||
# - t = _MODULE.sub(r":ref:`\1 <\1>`", t)
|
||||
# + t = _MODULE.sub(r":ref:`\1 <module_\1>`", t)
|
||||
#
|
||||
# These have @{module}@ in the template and need to have something like module_@{module}@
|
||||
# If any of these list plugins as well as modules, they will need to have a conditional or extra
|
||||
# data passed in to handle that in a generic fashion:
|
||||
#
|
||||
# docs/templates/list_of_CATEGORY_modules.rst.j2
|
||||
# docs/templates/list_of_CATEGORY_plugins.rst.j2
|
||||
# docs/templates/modules_by_support.rst.j2
|
||||
#
|
||||
# These are just a simple manual fix:
|
||||
# :ref:`command` matching plugin command was found in ./../docsite/rst/user_guide/intro_adhoc.rst
|
||||
# :ref:`shell` matching plugin shell was found in ./../docsite/rst/user_guide/intro_adhoc.rst
|
||||
# :ref:`config` matching plugin config was found in ./../docsite/rst/installation_guide/intro_configuration.rst
|
||||
@ -1,42 +0,0 @@
|
||||
#!/bin/sh
|
||||
|
||||
set -eux
|
||||
|
||||
FILENAME=../docsite/rst/dev_guide/testing/sanity/index.rst
|
||||
|
||||
cat <<- EOF >$FILENAME.new
|
||||
.. _all_sanity_tests:
|
||||
|
||||
Sanity Tests
|
||||
============
|
||||
|
||||
The following sanity tests are available as \`\`--test\`\` options for \`\`ansible-test sanity\`\`.
|
||||
This list is also available using \`\`ansible-test sanity --list-tests --allow-disabled\`\`.
|
||||
|
||||
For information on how to run these tests, see :ref:\`sanity testing guide <testing_sanity>\`.
|
||||
|
||||
.. toctree::
|
||||
:maxdepth: 1
|
||||
|
||||
$(for test in $(../../bin/ansible-test sanity --list-tests --allow-disabled); do echo " ${test}"; done)
|
||||
|
||||
EOF
|
||||
|
||||
# By default use sha1sum which exists on Linux, if not present select the correct binary
|
||||
# based on platform defaults
|
||||
SHA_CMD="sha1sum"
|
||||
if ! command -v ${SHA_CMD} > /dev/null 2>&1; then
|
||||
if command -v sha1 > /dev/null 2>&1; then
|
||||
SHA_CMD="sha1"
|
||||
elif command -v shasum > /dev/null 2>&1; then
|
||||
SHA_CMD="shasum"
|
||||
else
|
||||
# exit early with an error if no hashing binary can be found since it is required later
|
||||
exit 1
|
||||
fi
|
||||
fi
|
||||
|
||||
# Put file into place if it has changed
|
||||
if [ ! -f "${FILENAME}" ] || [ "$(${SHA_CMD} <$FILENAME)" != "$(${SHA_CMD} <$FILENAME.new)" ]; then
|
||||
mv -f $FILENAME.new $FILENAME
|
||||
fi
|
||||
19
docs/docsite/.gitignore
vendored
19
docs/docsite/.gitignore
vendored
@ -1,19 +0,0 @@
|
||||
# Old compiled python stuff
|
||||
*.py[co]
|
||||
# package building stuff
|
||||
build
|
||||
# Emacs backup files...
|
||||
*~
|
||||
.\#*
|
||||
.doctrees
|
||||
# Generated docs stuff
|
||||
ansible*.xml
|
||||
.buildinfo
|
||||
objects.inv
|
||||
.doctrees
|
||||
rst/dev_guide/testing/sanity/index.rst
|
||||
rst/modules/*.rst
|
||||
rst/playbooks_keywords.rst
|
||||
rst/collections/
|
||||
|
||||
*.min.css
|
||||
@ -1,77 +0,0 @@
|
||||
{% if is_eol %}
|
||||
{# 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="/ansible/latest/">the latest Ansible documentation</a>.</p>
|
||||
</div>
|
||||
{% else %}
|
||||
<script>
|
||||
function startsWith(str, needle) {
|
||||
return str.slice(0, needle.length) == needle
|
||||
}
|
||||
function startsWithOneOf(str, needles) {
|
||||
return needles.some(function (needle) {
|
||||
return startsWith(str, needle);
|
||||
});
|
||||
}
|
||||
var banner = '';
|
||||
var extra_banner = '';
|
||||
/*use extra_banner for when marketing wants something extra, like a survey or AnsibleFest notice */
|
||||
var extra_banner =
|
||||
'<div id="latest_extra_banner_id" class="admonition important">' +
|
||||
'<br>' +
|
||||
'<p>' +
|
||||
'<b>Experience AnsibleFest at Red Hat Summit</b>' +
|
||||
'</p>' +
|
||||
'<p>' +
|
||||
'We\'re bringing AnsibleFest to Red Hat Summit in Boston, May 23-25. It\'s the best of Fest combined with Red Hat Summit for even more learning and technical engagement. <a href="https://www.redhat.com/en/summit/ansiblefest?intcmp=7013a0000034lvhAAA">Learn more.</a> ' +
|
||||
|
||||
'</p>' +
|
||||
'<br>' +
|
||||
'</div>';
|
||||
// Create a banner if we're not on the official docs site
|
||||
if (location.host == "docs.testing.ansible.com") {
|
||||
document.write('<div id="testing_banner_id" class="admonition important">' +
|
||||
'<p>This is the testing site for Ansible Documentation. Unless you are reviewing pre-production changes, please visit the <a href="https://docs.ansible.com/ansible/latest/">official documentation website</a>.</p> <p></p>' +
|
||||
'</div>');
|
||||
}
|
||||
{% if available_versions is defined %}
|
||||
// Create a banner
|
||||
current_url_path = window.location.pathname;
|
||||
|
||||
var important = false;
|
||||
var msg = '<p>';
|
||||
if (startsWith(current_url_path, "/ansible-core/")) {
|
||||
msg += 'You are reading documentation for Ansible Core, which contains no plugins except for those in ansible.builtin. For documentation of the Ansible package, go to <a href="/ansible/latest">the latest documentation</a>.';
|
||||
} else if (startsWithOneOf(current_url_path, ["/ansible/latest/", "/ansible/{{ latest_version }}/"])) {
|
||||
/* temp extra banner to advertise AnsibeFest2021 */
|
||||
banner += extra_banner;
|
||||
|
||||
msg += 'You are reading the <b>latest</b> (stable) community version of the Ansible documentation. If you are a Red Hat customer, refer to the <a href="https://access.redhat.com/support/policy/updates/ansible-automation-platform">Ansible Automation Platform Life Cycle</a> page for subscription details.';
|
||||
} else if (startsWith(current_url_path, "/ansible/2.9/")) {
|
||||
msg += 'You are reading the latest Red Hat released version of the Ansible documentation. Community users can use this version, or select <b>latest</b> from the version selector to the left for the most recent community version.';
|
||||
} else if (startsWith(current_url_path, "/ansible/devel/")) {
|
||||
/* temp extra banner to advertise AnsibleFest2021 */
|
||||
banner += extra_banner;
|
||||
|
||||
/* temp banner to advertise survey
|
||||
important = true;
|
||||
msg += 'Please take our <a href="https://www.surveymonkey.co.uk/r/B9V3CDY">Docs survey</a> before December 31 to help us improve Ansible documentation.';
|
||||
*/
|
||||
|
||||
msg += 'You are reading the <b>devel</b> version of the Ansible documentation - this version is not guaranteed stable. Use the version selection to the left if you want the <b>latest</b> (stable) released version.';
|
||||
} else {
|
||||
msg += 'You are reading an older version of the Ansible documentation. Use the version selection to the left if you want the <b>latest</b> (stable) released version.';
|
||||
}
|
||||
msg += '</p>';
|
||||
|
||||
banner += '<div id="banner_id" class="admonition ';
|
||||
banner += important ? 'important' : 'caution';
|
||||
banner += '">';
|
||||
banner += important ? '<br>' : '';
|
||||
banner += msg;
|
||||
banner += important ? '<br>' : '';
|
||||
banner += '</div>';
|
||||
document.write(banner);
|
||||
{% endif %}
|
||||
</script>
|
||||
{% endif %}
|
||||
@ -1,52 +0,0 @@
|
||||
{%- extends "!breadcrumbs.html" %}
|
||||
{%- block breadcrumbs_aside %}
|
||||
<li class="wy-breadcrumbs-aside">
|
||||
{%- if hasdoc(pagename) and display_vcs_links %}
|
||||
{%- if display_github %}
|
||||
{%- if check_meta and 'github_url' in meta %}
|
||||
<!-- User defined GitHub URL -->
|
||||
<a href="{{ meta['github_url'] }}" class="fa fa-github"> {{ _('Edit on GitHub') }}</a>
|
||||
{%- else %}
|
||||
<!-- Ansible-specific additions for modules etc -->
|
||||
{% if check_meta and pagename.endswith((
|
||||
'_module', '_become', '_cache', '_callback',
|
||||
'_connection', '_inventory', '_lookup',
|
||||
'_shell', '_strategy', '_vars',
|
||||
)) %}
|
||||
{# <a href="https://{{ github_host|default("github.com") }}/{{ github_user }}/{{ github_repo }}/{{ theme_vcs_pageview_mode or "blob" }}/{{ github_module_version }}{{ meta.get('source', '') }}?description=%23%23%23%23%23%20SUMMARY%0A%3C!---%20Your%20description%20here%20--%3E%0A%0A%0A%23%23%23%23%23%20ISSUE%20TYPE%0A-%20Docs%20Pull%20Request%0A%0A%2Blabel:%20docsite_pr" class="fa fa-github"> {{ _('Edit on GitHub') }}</a> #}
|
||||
<br>
|
||||
<!-- Remove main index page as it is no longer editable -->
|
||||
{% elif pagename == 'index' %}
|
||||
<br>
|
||||
<!-- Remove all pages under collections/ as no longer editable -->
|
||||
{% elif pagename.startswith('collections/') %}
|
||||
<br>
|
||||
|
||||
{% elif check_meta and pagename.startswith('cli') and meta.get('source', None) %}
|
||||
<a href="https://{{ github_host|default("github.com") }}/{{ github_user }}/{{ github_repo }}/{{ theme_vcs_pageview_mode or "blob" }}/{{ github_cli_version }}{{ meta.get('source', '') }}?description=%23%23%23%23%23%20SUMMARY%0A%3C!---%20Your%20description%20here%20--%3E%0A%0A%0A%23%23%23%23%23%20ISSUE%20TYPE%0A-%20Docs%20Pull%20Request%0A%0A%2Blabel:%20docsite_pr" class="fa fa-github"> {{ _('Edit on GitHub') }}</a>
|
||||
{% elif (not 'list_of' in pagename) and (not 'category' in pagename) %}
|
||||
<a href="https://{{ github_host|default("github.com") }}/{{ github_user }}/{{ github_repo }}/{{ theme_vcs_pageview_mode or "blob" }}/{{ github_version }}{{ conf_py_path }}{{ pagename }}{{ page_source_suffix }}?description=%23%23%23%23%23%20SUMMARY%0A%3C!---%20Your%20description%20here%20--%3E%0A%0A%0A%23%23%23%23%23%20ISSUE%20TYPE%0A-%20Docs%20Pull%20Request%0A%0A%2Blabel:%20docsite_pr" class="fa fa-github"> {{ _('Edit on GitHub') }}</a>
|
||||
{% endif %}
|
||||
{%- endif %}
|
||||
{%- elif display_bitbucket %}
|
||||
{%- if check_meta and 'bitbucket_url' in meta %}
|
||||
<!-- User defined Bitbucket URL -->
|
||||
<a href="{{ meta['bitbucket_url'] }}" class="fa fa-bitbucket"> {{ _('Edit on Bitbucket') }}</a>
|
||||
{%- else %}
|
||||
<a href="https://bitbucket.org/{{ bitbucket_user }}/{{ bitbucket_repo }}/src/{{ bitbucket_version}}{{ conf_py_path }}{{ pagename }}{{ page_source_suffix }}?mode={{ theme_vcs_pageview_mode or "view" }}" class="fa fa-bitbucket"> {{ _('Edit on Bitbucket') }}</a>
|
||||
{%- endif %}
|
||||
{%- elif display_gitlab %}
|
||||
{%- if check_meta and 'gitlab_url' in meta %}
|
||||
<!-- User defined GitLab URL -->
|
||||
<a href="{{ meta['gitlab_url'] }}" class="fa fa-gitlab"> {{ _('Edit on GitLab') }}</a>
|
||||
{%- else %}
|
||||
<a href="https://{{ gitlab_host|default("gitlab.com") }}/{{ gitlab_user }}/{{ gitlab_repo }}/{{ theme_vcs_pageview_mode or "blob" }}/{{ gitlab_version }}{{ conf_py_path }}{{ pagename }}{{ page_source_suffix }}" class="fa fa-gitlab"> {{ _('Edit on GitLab') }}</a>
|
||||
{%- endif %}
|
||||
{%- elif show_source and source_url_prefix %}
|
||||
<a href="{{ source_url_prefix }}{{ pagename }}{{ page_source_suffix }}">{{ _('View page source') }}</a>
|
||||
{%- elif show_source and has_source and sourcename %}
|
||||
<a href="{{ pathto('_sources/' + sourcename, true)|e }}" rel="nofollow"> {{ _('View page source') }}</a>
|
||||
{%- endif %}
|
||||
{%- endif %}
|
||||
</li>
|
||||
{%- endblock %}
|
||||
@ -1,4 +0,0 @@
|
||||
{# https://jinja.palletsprojects.com/en/3.0.x/tricks/#null-default-fallback #}
|
||||
{%- if not is_eol %}
|
||||
{%- extends "!version_chooser.html" %}
|
||||
{%- endif %}
|
||||
@ -1,220 +0,0 @@
|
||||
OS := $(shell uname -s)
|
||||
PLUGIN_FORMATTER=../../hacking/build-ansible.py docs-build
|
||||
TESTING_FORMATTER=../bin/testing_formatter.sh
|
||||
KEYWORD_DUMPER=../../hacking/build-ansible.py document-keywords
|
||||
CONFIG_DUMPER=../../hacking/build-ansible.py document-config
|
||||
GENERATE_CLI=../../hacking/build-ansible.py generate-man
|
||||
COLLECTION_DUMPER=../../hacking/build-ansible.py collection-meta
|
||||
ifeq ($(shell echo $(OS) | egrep -ic 'Darwin|FreeBSD|OpenBSD|DragonFly'),1)
|
||||
CPUS ?= $(shell sysctl hw.ncpu|awk '{print $$2}')
|
||||
else
|
||||
CPUS ?= $(shell nproc)
|
||||
endif
|
||||
|
||||
# Intenationalisation and Localisation
|
||||
LANGUAGES ?=
|
||||
|
||||
# Sets the build output directory for the main docsite if it's not already specified
|
||||
ifndef BUILDDIR
|
||||
BUILDDIR = _build
|
||||
endif
|
||||
|
||||
ifndef POTDIR
|
||||
POTDIR = $(BUILDDIR)/gettext
|
||||
endif
|
||||
|
||||
# Backwards compat for separate VARS
|
||||
PLUGIN_ARGS=
|
||||
ifdef MODULES
|
||||
ifndef PLUGINS
|
||||
PLUGIN_ARGS = -l $(MODULES)
|
||||
else
|
||||
PLUGIN_ARGS = -l $(MODULES),$(PLUGINS)
|
||||
endif
|
||||
else
|
||||
ifdef PLUGINS
|
||||
PLUGIN_ARGS = -l $(PLUGINS)
|
||||
endif
|
||||
endif
|
||||
|
||||
ANSIBLE_VERSION_ARGS=
|
||||
ifdef ANSIBLE_VERSION
|
||||
ANSIBLE_VERSION_ARGS=--ansible-version=$(ANSIBLE_VERSION)
|
||||
endif
|
||||
|
||||
DOC_PLUGINS ?= become cache callback cliconf connection httpapi inventory lookup netconf shell strategy vars
|
||||
|
||||
PYTHON ?= python
|
||||
# fetch version from project release.py as single source-of-truth
|
||||
VERSION := $(shell $(PYTHON) ../../packaging/release/versionhelper/version_helper.py --raw || echo error)
|
||||
ifeq ($(findstring error,$(VERSION)), error)
|
||||
$(error "version_helper failed")
|
||||
endif
|
||||
|
||||
MAJOR_VERSION := $(shell $(PYTHON) ../../packaging/release/versionhelper/version_helper.py --majorversion || echo error)
|
||||
ifeq ($(findstring error,$(MAJOR_VERSION)), error)
|
||||
$(error "version_helper failed to determine major version")
|
||||
endif
|
||||
|
||||
|
||||
assertrst:
|
||||
ifndef rst
|
||||
$(error specify document or pattern with rst=somefile.rst)
|
||||
endif
|
||||
|
||||
all: docs
|
||||
|
||||
docs: htmldocs
|
||||
|
||||
coredocs: core_htmldocs
|
||||
|
||||
|
||||
generate_rst: collections_meta config cli keywords plugins testing
|
||||
core_generate_rst: collections_meta config cli keywords core_plugins testing
|
||||
|
||||
# At the moment localizing the plugins and collections is not required for the ongoing
|
||||
# localisation effort. It will come at a later time.
|
||||
gettext_generate_rst: collections_meta config cli keywords testing
|
||||
|
||||
# The following symlinks are necessary to produce two different docsets
|
||||
# from the same set of rst files (Ansible the package docs, and core docs).
|
||||
# Symlink the relevant index into place for building Ansible docs
|
||||
ansible_structure:
|
||||
# We must have python and python-packaging for the version_helper
|
||||
# script so use it for version comparison
|
||||
if $(PYTHON) -c "import sys, packaging.version as p; sys.exit(not p.Version('$(MAJOR_VERSION)') > p.Version('2.10'))" ; then \
|
||||
echo "Creating symlinks in ansible_structure"; \
|
||||
ln -sf ../rst/ansible_index.rst rst/index.rst; \
|
||||
ln -sf ../dev_guide/ansible_index.rst rst/dev_guide/index.rst; \
|
||||
ln -sf ../sphinx_conf/ansible_conf.py rst/conf.py; \
|
||||
else \
|
||||
echo 'Creating symlinks for older ansible in ansible_structure'; \
|
||||
ln -sf ../rst/2.10_index.rst rst/index.rst; \
|
||||
ln -sf ../sphinx_conf/2.10_conf.py rst/conf.py; \
|
||||
fi
|
||||
|
||||
# Symlink the relevant index into place for building core docs
|
||||
core_structure:
|
||||
@echo "Creating symlinks in core_structure"
|
||||
-ln -sf ../rst/core_index.rst rst/index.rst
|
||||
-ln -sf ../dev_guide/core_index.rst rst/dev_guide/index.rst
|
||||
# set up the correct core conf.py to use for English vs a translated language
|
||||
ifdef LANGOPTS
|
||||
-ln -sf ../sphinx_conf/core_lang_conf.py rst/conf.py
|
||||
else
|
||||
-ln -sf ../sphinx_conf/core_conf.py rst/conf.py
|
||||
endif
|
||||
|
||||
# Symlink the relevant index into place for building core translated docs
|
||||
gettext_structure:
|
||||
@echo "Creating symlinks in gettext_structure"
|
||||
-ln -sf ../rst/core_index.rst rst/index.rst
|
||||
-ln -sf ../rst/dev_guide/core_index.rst rst/dev_guide/index.rst
|
||||
-ln -sf ../sphinx_conf/all_conf.py rst/conf.py
|
||||
|
||||
gettext: gettext_structure gettext_generate_rst
|
||||
CPUS=$(CPUS) $(MAKE) -f Makefile.sphinx gettext
|
||||
# if msgcat is installed handle all indexes, otherwise use the index from gettext_structure.
|
||||
-msgcat "$(POTDIR)/core_index.pot" "$(POTDIR)/ansible_index.pot" "$(POTDIR)/2.10_index.pot" > "$(POTDIR)/tmp_index.pot" && mv "$(POTDIR)/tmp_index.pot" "$(POTDIR)/index.pot"
|
||||
rm "$(POTDIR)/core_index.pot" "$(POTDIR)/ansible_index.pot" "$(POTDIR)/2.10_index.pot"
|
||||
|
||||
generate-po:
|
||||
ifeq ($(LANGUAGES),)
|
||||
@echo 'LANGUAGES is not defined. It is mandatory. LANGUAGES should be a comma separated list of languages to support. (Exampe: fr,es)'
|
||||
else
|
||||
(cd docs/docsite/; sphinx-intl update -w 0 -d rst/locales -p "$(POTDIR)" -l $(LANGUAGES))
|
||||
endif
|
||||
|
||||
needs-translation:
|
||||
ifeq ($(LANGUAGES),)
|
||||
@echo 'LANGUAGES is not defined. It is mandatory. LANGUAGES should be a comma separated list of languages to support. (Exampe: fr,es)'
|
||||
else
|
||||
(cd docs/docsite/; sphinx-intl stat -d rst/locales -l $(LANGUAGES) | grep -E ' [1-9][0-9]* (fuzzy|untranslated)' | sort)
|
||||
endif
|
||||
|
||||
htmldocs: ansible_structure generate_rst
|
||||
CPUS=$(CPUS) $(MAKE) -f Makefile.sphinx html
|
||||
|
||||
core_htmldocs: core_structure core_generate_rst
|
||||
CPUS=$(CPUS) $(MAKE) -f Makefile.sphinx html
|
||||
|
||||
singlehtmldocs: ansible_structure generate_rst
|
||||
CPUS=$(CPUS) $(MAKE) -f Makefile.sphinx singlehtml
|
||||
|
||||
core_singlehtmldocs: core_structure core_generate_rst
|
||||
CPUS=$(CPUS) $(MAKE) -f Makefile.sphinx singlehtml
|
||||
|
||||
# Note: The linkcheckdocs and htmlsingle targets depend on gettext_structure
|
||||
# because that one does not exclude any rst files in its conf.py.
|
||||
linkcheckdocs: gettext_structure generate_rst
|
||||
CPUS=$(CPUS) $(MAKE) -f Makefile.sphinx linkcheck
|
||||
|
||||
htmlsingle: assertrst gettext_structure
|
||||
sphinx-build -j $(CPUS) -b html -d $(BUILDDIR)/doctrees ./rst $(BUILDDIR)/html rst/$(rst)
|
||||
@echo "Output is in $(BUILDDIR)/html/$(rst:.rst=.html)"
|
||||
|
||||
webdocs: docs
|
||||
|
||||
#TODO: leaving htmlout removal for those having older versions, should eventually be removed also
|
||||
clean:
|
||||
@echo "Cleaning $(BUILDDIR)"
|
||||
-rm -rf $(BUILDDIR)/doctrees
|
||||
-rm -rf $(BUILDDIR)/html
|
||||
-rm -rf htmlout
|
||||
-rm -rf module_docs
|
||||
-rm -rf $(BUILDDIR)
|
||||
-rm -f .buildinfo
|
||||
-rm -f objects.inv
|
||||
-rm -rf *.doctrees
|
||||
@echo "Cleaning up minified css files"
|
||||
find . -type f -name "*.min.css" -delete
|
||||
@echo "Cleaning up byte compiled python stuff"
|
||||
find . -regex ".*\.py[co]$$" -delete
|
||||
@echo "Cleaning up editor backup files"
|
||||
find . -type f \( -name "*~" -or -name "#*" \) -delete
|
||||
find . -type f \( -name "*.swp" \) -delete
|
||||
@echo "Cleaning up generated rst"
|
||||
rm -f rst/playbooks_directives.rst
|
||||
rm -f rst/reference_appendices/config.rst
|
||||
rm -f rst/reference_appendices/playbooks_keywords.rst
|
||||
rm -f rst/dev_guide/collections_galaxy_meta.rst
|
||||
rm -f rst/cli/*.rst
|
||||
for filename in `ls rst/collections/` ; do \
|
||||
if test x"$$filename" != x'all_plugins.rst' ; then \
|
||||
rm -rf "rst/collections/$$filename"; \
|
||||
fi \
|
||||
done
|
||||
@echo "Cleaning up generated ansible_structure"
|
||||
find . -type l -delete
|
||||
@echo "Cleaning up legacy generated rst locations"
|
||||
rm -rf rst/modules
|
||||
rm -f rst/plugins/*/*.rst
|
||||
|
||||
.PHONY: docs clean
|
||||
|
||||
collections_meta: ../templates/collections_galaxy_meta.rst.j2
|
||||
$(COLLECTION_DUMPER) --template-file=../templates/collections_galaxy_meta.rst.j2 --output-dir=rst/dev_guide/ $(EXTRA_COLLECTION_META_ARGS) ../../lib/ansible/galaxy/data/collections_galaxy_meta.yml
|
||||
|
||||
# TODO: make generate_man output dir cli option
|
||||
cli:
|
||||
mkdir -p rst/cli
|
||||
$(GENERATE_CLI) --template-file=../templates/cli_rst.j2 --output-dir=rst/cli/ --output-format rst $(EXTRA_CLI_DUMPER_ARGS) ../../lib/ansible/cli/*.py
|
||||
|
||||
keywords: ../templates/playbooks_keywords.rst.j2
|
||||
$(KEYWORD_DUMPER) --template-dir=../templates --output-dir=rst/reference_appendices/ ../../lib/ansible/keyword_desc.yml $(EXTRA_KEYWORD_DUMPER_ARGS)
|
||||
|
||||
config: ../templates/config.rst.j2
|
||||
$(CONFIG_DUMPER) --template-file=../templates/config.rst.j2 --output-dir=rst/reference_appendices/ $(EXTRA_CONFIG_DUMPER_ARGS) ../../lib/ansible/config/base.yml
|
||||
|
||||
plugins:
|
||||
$(PLUGIN_FORMATTER) full -o rst $(ANSIBLE_VERSION_ARGS) $(EXTRA_PLUGIN_FORMATTER_ARGS) $(PLUGIN_ARGS)
|
||||
|
||||
# This only builds the plugin docs included with ansible-core
|
||||
core_plugins:
|
||||
$(PLUGIN_FORMATTER) core -o rst $(EXTRA_PLUGIN_FORMATTER_ARGS) $(PLUGIN_ARGS)
|
||||
|
||||
testing:
|
||||
$(TESTING_FORMATTER)
|
||||
|
||||
epub:
|
||||
(CPUS=$(CPUS) $(MAKE) -f Makefile.sphinx epub)
|
||||
@ -1,26 +0,0 @@
|
||||
# Minimal makefile for Sphinx documentation
|
||||
#
|
||||
|
||||
# You can set these variables from the command line.
|
||||
SPHINXCONFDIR = rst
|
||||
LANGOPTS ?=
|
||||
SPHINXOPTS ?= -j $(CPUS) -n -w rst_warnings -c "$(SPHINXCONFDIR)" $(LANGOPTS)
|
||||
SPHINXBUILD = sphinx-build
|
||||
SPHINXPROJ = sdfsdf
|
||||
SOURCEDIR = rst
|
||||
|
||||
# Sets the build output directory if it's not specified on the command line
|
||||
ifndef BUILDDIR
|
||||
BUILDDIR = _build
|
||||
endif
|
||||
|
||||
# Put it first so that "make" without argument is like "make help".
|
||||
help:
|
||||
$(SPHINXBUILD) -M help "$(SOURCEDIR)" "$(BUILDDIR)" $(SPHINXOPTS) $(O)
|
||||
|
||||
.PHONY: help Makefile.sphinx
|
||||
|
||||
# Catch-all target: route all unknown targets to Sphinx using the new
|
||||
# "make mode" option. $(O) is meant as a shortcut for $(SPHINXOPTS).
|
||||
%: Makefile.sphinx
|
||||
$(SPHINXBUILD) -M $@ "$(SOURCEDIR)" "$(BUILDDIR)" $(SPHINXOPTS) $(O)
|
||||
@ -1,26 +0,0 @@
|
||||
Ansible documentation
|
||||
=====================
|
||||
|
||||
This project hosts the source behind the general pages of [docs.ansible.com](https://docs.ansible.com/). Module-specific documentation is hosted in the various collections repositories. See [Ansible Galaxy](https://galaxy.ansible.com/), the list of [Ansible-maintained collections](https://docs.ansible.com/ansible/devel/community/contributing_maintained_collections.html), and the [ansible-collections organization](https://github.com/ansible-collections) for collections sources.
|
||||
|
||||
To create clear, concise, and consistent contributions to Ansible documentation, please refer to the following information.
|
||||
|
||||
Contributions
|
||||
=============
|
||||
Contributions to the documentation are welcome.
|
||||
|
||||
The Ansible community produces guidance on contributions, building documentation, and submitting pull requests, which you can find in [Contributing to the Ansible Documentation](https://docs.ansible.com/ansible/latest/community/documentation_contributions.html).
|
||||
|
||||
You can also join the [Docs Working Group](https://github.com/ansible/community/wiki/Docs) and/or the ``#ansible-docs`` IRC channel on [irc.libera.chat](https://libera.chat/)
|
||||
|
||||
Ansible style guide
|
||||
===================
|
||||
Ansible documentation is written in ReStructuredText(RST). The [Ansible style guide](https://docs.ansible.com/ansible/latest/dev_guide/style_guide/index.html#linguistic-guidelines) provides linguistic direction and technical guidelines for working with reStructuredText, in addition to other resources.
|
||||
|
||||
Tools
|
||||
=====
|
||||
The Ansible community uses a range of tools and programs for working with Ansible documentation. Learn more about [Other Tools and Programs](https://docs.ansible.com/ansible/latest/community/other_tools_and_programs.html#popular-editors) in the Ansible Community Guide.
|
||||
|
||||
GitHub
|
||||
======
|
||||
[Ansible documentation](https://github.com/ansible/ansible/tree/devel/docs/docsite) is hosted on the Ansible GitHub project and various collection repositories, especially those in the [ansible-collections organization](https://github.com/ansible-collections). For general GitHub workflows and other information, see the [GitHub Guides](https://guides.github.com/).
|
||||
@ -1,17 +0,0 @@
|
||||
.DocSiteProduct-header--core {
|
||||
background-color: #161b1f;
|
||||
border-color: #161b1f;
|
||||
}
|
||||
|
||||
.wy-nav-top, .wy-side-nav-search {
|
||||
background-color: #161b1f;
|
||||
}
|
||||
.wy-nav-side {
|
||||
background-color: #999999;
|
||||
}
|
||||
.wy-menu-vertical header, .wy-menu-vertical p.caption {
|
||||
color: #161b1f;
|
||||
}
|
||||
.ansibleNav ul li a:hover {
|
||||
color: #161b1f;
|
||||
}
|
||||
Binary file not shown.
Binary file not shown.
Binary file not shown.
@ -1,17 +0,0 @@
|
||||
# We also need an example of modules hosted in Automation Hub
|
||||
# We'll likely move to data hosted in botmeta instead of a standalone file but
|
||||
# we'll need all of these same details.
|
||||
module:
|
||||
purefa_user:
|
||||
source: 'https://galaxy.ansible.com/'
|
||||
fqcn: 'purestorage.flasharray'
|
||||
purefa_vg:
|
||||
source: 'https://galaxy.ansible.com/'
|
||||
fqcn: 'purestorage.flasharray'
|
||||
gcp_compute_firewall_info:
|
||||
source: 'https://galaxy.ansible.com/'
|
||||
fqcn: 'google.cloud'
|
||||
module_utils:
|
||||
purefa:
|
||||
source: 'https://galaxy.ansible.com/'
|
||||
fqcn: 'purestorage.flasharray'
|
||||
Binary file not shown.
@ -1,14 +0,0 @@
|
||||
# pip packages required to build docsite
|
||||
# These requirements drift from test/sanity/code-smell/docs-build.requirements.txt
|
||||
# only for antsibull-docs minor (bugfix) releases.
|
||||
|
||||
jinja2==3.1.2
|
||||
PyYAML==6.0
|
||||
resolvelib==0.8.1
|
||||
rstcheck==3.5.0
|
||||
sphinx == 4.2.0
|
||||
sphinx-ansible-theme==0.9.1
|
||||
sphinx-notfound-page==0.8.3
|
||||
straight.plugin==1.5.0
|
||||
antsibull-docs == 1.7.3 # Drifted from CI. currently approved version
|
||||
|
||||
@ -1,5 +0,0 @@
|
||||
function AnsibleModules($scope) {
|
||||
$scope.modules = [];
|
||||
|
||||
$scope.orderProp = "module";
|
||||
}
|
||||
Binary file not shown.
Binary file not shown.
@ -1,17 +0,0 @@
|
||||
# pip packages required to build docsite
|
||||
# these requirements are as loosely defined as possible
|
||||
# if you want known good versions of these dependencies
|
||||
# use test/sanity/code-smell/docs-build.requirements.txt
|
||||
# instead
|
||||
|
||||
antsibull-docs >= 1.0.0, < 2.0.0
|
||||
docutils
|
||||
jinja2
|
||||
pygments >= 2.10.0
|
||||
pyyaml
|
||||
rstcheck
|
||||
sphinx
|
||||
sphinx-notfound-page >= 0.6
|
||||
sphinx-intl
|
||||
sphinx-ansible-theme >= 0.9.1
|
||||
resolvelib
|
||||
@ -1,106 +0,0 @@
|
||||
.. _ansible_documentation:
|
||||
|
||||
Ansible Documentation
|
||||
=====================
|
||||
|
||||
About Ansible
|
||||
`````````````
|
||||
|
||||
Ansible is an IT automation tool. It can configure systems, deploy software, and orchestrate more advanced IT tasks such as continuous deployments or zero downtime rolling updates.
|
||||
|
||||
Ansible's main goals are simplicity and ease-of-use. It also has a strong focus on security and reliability, featuring a minimum of moving parts, usage of OpenSSH for transport (with other transports and pull modes as alternatives), and a language that is designed around auditability by humans--even those not familiar with the program.
|
||||
|
||||
We believe simplicity is relevant to all sizes of environments, so we design for busy users of all types: developers, sysadmins, release engineers, IT managers, and everyone in between. Ansible is appropriate for managing all environments, from small setups with a handful of instances to enterprise environments with many thousands of instances.
|
||||
|
||||
You can learn more at `AnsibleFest <https://www.ansible.com/ansiblefest>`_, the annual event for all Ansible contributors, users, and customers hosted by Red Hat. AnsibleFest is the place to connect with others, learn new skills, and find a new friend to automate with.
|
||||
|
||||
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 version of Ansible noted in the upper left corner of this page. We maintain multiple versions of Ansible and of the documentation, so please be sure you are using the version of the documentation that covers the version of Ansible you're using. For recent features, we note the version of Ansible where the feature was added.
|
||||
|
||||
Ansible releases a new major release approximately twice a year. The core application evolves somewhat conservatively, valuing simplicity in language design and setup. Contributors develop and change modules and plugins, hosted in collections since version 2.10, much more quickly.
|
||||
|
||||
.. toctree::
|
||||
:maxdepth: 2
|
||||
:caption: Installation, Upgrade & Configuration
|
||||
|
||||
installation_guide/index
|
||||
porting_guides/porting_guides
|
||||
|
||||
.. toctree::
|
||||
:maxdepth: 2
|
||||
:caption: Using Ansible
|
||||
|
||||
user_guide/index
|
||||
|
||||
.. toctree::
|
||||
:maxdepth: 2
|
||||
:caption: Contributing to Ansible
|
||||
|
||||
community/index
|
||||
|
||||
.. toctree::
|
||||
:maxdepth: 2
|
||||
:caption: Extending Ansible
|
||||
|
||||
dev_guide/index
|
||||
|
||||
.. toctree::
|
||||
:glob:
|
||||
:maxdepth: 1
|
||||
:caption: Common Ansible Scenarios
|
||||
|
||||
scenario_guides/cloud_guides
|
||||
scenario_guides/network_guides
|
||||
scenario_guides/virt_guides
|
||||
|
||||
.. toctree::
|
||||
:maxdepth: 2
|
||||
:caption: Network Automation
|
||||
|
||||
network/getting_started/index
|
||||
network/user_guide/index
|
||||
network/dev_guide/index
|
||||
|
||||
.. toctree::
|
||||
:maxdepth: 2
|
||||
:caption: Ansible Galaxy
|
||||
|
||||
galaxy/user_guide.rst
|
||||
galaxy/dev_guide.rst
|
||||
|
||||
|
||||
.. toctree::
|
||||
:maxdepth: 1
|
||||
:caption: Reference & Appendices
|
||||
|
||||
collections/index
|
||||
collections/all_plugins
|
||||
reference_appendices/playbooks_keywords
|
||||
reference_appendices/common_return_values
|
||||
reference_appendices/config
|
||||
reference_appendices/general_precedence
|
||||
reference_appendices/YAMLSyntax
|
||||
reference_appendices/python_3_support
|
||||
reference_appendices/interpreter_discovery
|
||||
reference_appendices/release_and_maintenance
|
||||
reference_appendices/test_strategies
|
||||
dev_guide/testing/sanity/index
|
||||
reference_appendices/faq
|
||||
reference_appendices/glossary
|
||||
reference_appendices/module_utils
|
||||
reference_appendices/special_variables
|
||||
reference_appendices/tower
|
||||
reference_appendices/automationhub
|
||||
reference_appendices/logging
|
||||
|
||||
|
||||
.. toctree::
|
||||
:maxdepth: 2
|
||||
:caption: Release Notes
|
||||
|
||||
.. toctree::
|
||||
:maxdepth: 2
|
||||
:caption: Roadmaps
|
||||
|
||||
roadmap/index.rst
|
||||
@ -1,12 +0,0 @@
|
||||
:orphan:
|
||||
|
||||
*****
|
||||
Oops!
|
||||
*****
|
||||
|
||||
The version of the Ansible documentation you were looking at doesn't contain that page.
|
||||
|
||||
.. image:: images/cow.png
|
||||
:alt: Cowsay 404
|
||||
|
||||
Use the back button to return to the version you were browsing, or use the navigation at left to explore our latest release. Once you're on a non-404 page, you can use the version-changer to select a version.
|
||||
@ -1,124 +0,0 @@
|
||||
.. _ansible_documentation:
|
||||
..
|
||||
This is the index file for Ansible the package. It gets symlinked to index.rst by the Makefile
|
||||
|
||||
Ansible Documentation
|
||||
=====================
|
||||
|
||||
About Ansible
|
||||
`````````````
|
||||
|
||||
Ansible is an IT automation tool. It can configure systems, deploy software, and orchestrate more advanced IT tasks such as continuous deployments or zero downtime rolling updates.
|
||||
|
||||
Ansible's main goals are simplicity and ease-of-use. It also has a strong focus on security and reliability, featuring a minimum of moving parts, usage of OpenSSH for transport (with other transports and pull modes as alternatives), and a language that is designed around auditability by humans--even those not familiar with the program.
|
||||
|
||||
We believe simplicity is relevant to all sizes of environments, so we design for busy users of all types: developers, sysadmins, release engineers, IT managers, and everyone in between. Ansible is appropriate for managing all environments, from small setups with a handful of instances to enterprise environments with many thousands of instances.
|
||||
|
||||
You can learn more at `AnsibleFest <https://www.ansible.com/ansiblefest>`_, the annual event for all Ansible contributors, users, and customers hosted by Red Hat. AnsibleFest is the place to connect with others, learn new skills, and find a new friend to automate with.
|
||||
|
||||
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. Also, security exposure is greatly reduced because Ansible uses OpenSSH — the open source connectivity tool for remote login with the SSH (Secure Shell) protocol.
|
||||
|
||||
Ansible is decentralized--it relies on your existing OS credentials to control access to remote machines. And if needed, Ansible can easily connect with Kerberos, LDAP, and other centralized authentication management systems.
|
||||
|
||||
This documentation covers the version of Ansible noted in the upper left corner of this page. We maintain multiple versions of Ansible and the Ansible documentation, so please be sure you are using the documentation version that covers the version of Ansible you are using. For recent features, we note the version of Ansible where the feature was added.
|
||||
|
||||
Ansible releases a new major release approximately twice a year. The core application evolves somewhat conservatively, valuing simplicity in language design and setup. Contributors develop and change modules and plugins hosted in collections since version 2.10 much more quickly.
|
||||
|
||||
.. toctree::
|
||||
:maxdepth: 2
|
||||
:caption: Ansible getting started
|
||||
|
||||
getting_started/index
|
||||
|
||||
.. toctree::
|
||||
:maxdepth: 2
|
||||
:caption: Installation, Upgrade & Configuration
|
||||
|
||||
installation_guide/index
|
||||
porting_guides/porting_guides
|
||||
|
||||
.. toctree::
|
||||
:maxdepth: 2
|
||||
:caption: Using Ansible
|
||||
|
||||
inventory_guide/index
|
||||
command_guide/index
|
||||
playbook_guide/index
|
||||
vault_guide/index
|
||||
module_plugin_guide/index
|
||||
collections_guide/index
|
||||
os_guide/index
|
||||
tips_tricks/index
|
||||
|
||||
.. toctree::
|
||||
:maxdepth: 2
|
||||
:caption: Contributing to Ansible
|
||||
|
||||
community/index
|
||||
community/contributions_collections
|
||||
community/contributions
|
||||
community/advanced_index
|
||||
dev_guide/style_guide/index
|
||||
|
||||
.. toctree::
|
||||
:maxdepth: 2
|
||||
:caption: Extending Ansible
|
||||
|
||||
dev_guide/index
|
||||
|
||||
.. toctree::
|
||||
:glob:
|
||||
:maxdepth: 1
|
||||
:caption: Common Ansible Scenarios
|
||||
|
||||
scenario_guides/cloud_guides
|
||||
scenario_guides/network_guides
|
||||
scenario_guides/virt_guides
|
||||
|
||||
.. toctree::
|
||||
:maxdepth: 2
|
||||
:caption: Network Automation
|
||||
|
||||
network/getting_started/index
|
||||
network/user_guide/index
|
||||
network/dev_guide/index
|
||||
|
||||
.. toctree::
|
||||
:maxdepth: 2
|
||||
:caption: Ansible Galaxy
|
||||
|
||||
galaxy/user_guide.rst
|
||||
galaxy/dev_guide.rst
|
||||
|
||||
|
||||
.. toctree::
|
||||
:maxdepth: 1
|
||||
:caption: Reference & Appendices
|
||||
|
||||
collections/index
|
||||
collections/all_plugins
|
||||
reference_appendices/playbooks_keywords
|
||||
reference_appendices/common_return_values
|
||||
reference_appendices/config
|
||||
reference_appendices/general_precedence
|
||||
reference_appendices/YAMLSyntax
|
||||
reference_appendices/python_3_support
|
||||
reference_appendices/interpreter_discovery
|
||||
reference_appendices/release_and_maintenance
|
||||
reference_appendices/test_strategies
|
||||
dev_guide/testing/sanity/index
|
||||
reference_appendices/faq
|
||||
reference_appendices/glossary
|
||||
reference_appendices/module_utils
|
||||
reference_appendices/special_variables
|
||||
reference_appendices/tower
|
||||
reference_appendices/automationhub
|
||||
reference_appendices/logging
|
||||
|
||||
|
||||
.. toctree::
|
||||
:maxdepth: 2
|
||||
:caption: Roadmaps
|
||||
|
||||
roadmap/ansible_roadmap_index.rst
|
||||
roadmap/ansible_core_roadmap_index.rst
|
||||
@ -1,107 +0,0 @@
|
||||
:orphan:
|
||||
|
||||
*************************
|
||||
Ansible API Documentation
|
||||
*************************
|
||||
|
||||
The Ansible API is under construction. These stub references for attributes, classes, functions, methods, and modules will be documented in future.
|
||||
The :ref:`module utilities <ansible.module_utils>` included in ``ansible.module_utils.basic`` and ``AnsibleModule`` are documented under Reference & Appendices.
|
||||
|
||||
.. contents::
|
||||
:local:
|
||||
|
||||
Attributes
|
||||
==========
|
||||
|
||||
.. py:attribute:: AnsibleModule.params
|
||||
|
||||
The parameters accepted by the module.
|
||||
|
||||
.. py:attribute:: ansible.module_utils.basic.ANSIBLE_VERSION
|
||||
|
||||
.. py:attribute:: ansible.module_utils.basic.SELINUX_SPECIAL_FS
|
||||
|
||||
Deprecated in favor of ansibleModule._selinux_special_fs.
|
||||
|
||||
.. py:attribute:: AnsibleModule.ansible_version
|
||||
|
||||
.. py:attribute:: AnsibleModule._debug
|
||||
|
||||
.. py:attribute:: AnsibleModule._diff
|
||||
|
||||
.. py:attribute:: AnsibleModule.no_log
|
||||
|
||||
.. py:attribute:: AnsibleModule._selinux_special_fs
|
||||
|
||||
(formerly ansible.module_utils.basic.SELINUX_SPECIAL_FS)
|
||||
|
||||
.. py:attribute:: AnsibleModule._syslog_facility
|
||||
|
||||
.. py:attribute:: self.playbook
|
||||
|
||||
.. py:attribute:: self.play
|
||||
|
||||
.. py:attribute:: self.task
|
||||
|
||||
.. py:attribute:: sys.path
|
||||
|
||||
|
||||
Classes
|
||||
=======
|
||||
|
||||
.. py:class:: ``ansible.module_utils.basic.AnsibleModule``
|
||||
:noindex:
|
||||
|
||||
The basic utilities for AnsibleModule.
|
||||
|
||||
.. py:class:: AnsibleModule
|
||||
|
||||
The main class for an Ansible module.
|
||||
|
||||
|
||||
Functions
|
||||
=========
|
||||
|
||||
.. py:function:: ansible.module_utils.basic._load_params()
|
||||
|
||||
Load parameters.
|
||||
|
||||
|
||||
Methods
|
||||
=======
|
||||
|
||||
.. py:method:: AnsibleModule.log()
|
||||
|
||||
Logs the output of Ansible.
|
||||
|
||||
.. py:method:: AnsibleModule.debug()
|
||||
|
||||
Debugs Ansible.
|
||||
|
||||
.. py:method:: Ansible.get_bin_path()
|
||||
|
||||
Retrieves the path for executables.
|
||||
|
||||
.. py:method:: AnsibleModule.run_command()
|
||||
|
||||
Runs a command within an Ansible module.
|
||||
|
||||
.. py:method:: module.fail_json()
|
||||
|
||||
Exits and returns a failure.
|
||||
|
||||
.. py:method:: module.exit_json()
|
||||
|
||||
Exits and returns output.
|
||||
|
||||
|
||||
Modules
|
||||
=======
|
||||
|
||||
.. py:module:: ansible.module_utils
|
||||
|
||||
.. py:module:: ansible.module_utils.basic
|
||||
:noindex:
|
||||
|
||||
|
||||
.. py:module:: ansible.module_utils.url
|
||||
@ -1,11 +0,0 @@
|
||||
.. _all_modules_and_plugins:
|
||||
|
||||
Indexes of all modules and plugins
|
||||
----------------------------------
|
||||
|
||||
.. toctree::
|
||||
:maxdepth: 1
|
||||
:caption: Plugin indexes
|
||||
:glob:
|
||||
|
||||
index_*
|
||||
@ -1,77 +0,0 @@
|
||||
.. _collections_downloading:
|
||||
|
||||
Downloading collections
|
||||
=======================
|
||||
|
||||
To download a collection and its dependencies for an offline install, run ``ansible-galaxy collection download``. This
|
||||
downloads the collections specified and their dependencies to the specified folder and creates a ``requirements.yml``
|
||||
file which can be used to install those collections on a host without access to a Galaxy server. All the collections
|
||||
are downloaded by default to the ``./collections`` folder.
|
||||
|
||||
Just like the ``install`` command, the collections are sourced based on the
|
||||
:ref:`configured galaxy server config <galaxy_server_config>`. Even if a collection to download was specified by a URL
|
||||
or path to a tarball, the collection will be redownloaded from the configured Galaxy server.
|
||||
|
||||
Collections can be specified as one or multiple collections or with a ``requirements.yml`` file just like
|
||||
``ansible-galaxy collection install``.
|
||||
|
||||
To download a single collection and its dependencies:
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
ansible-galaxy collection download my_namespace.my_collection
|
||||
|
||||
To download a single collection at a specific version:
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
ansible-galaxy collection download my_namespace.my_collection:1.0.0
|
||||
|
||||
To download multiple collections either specify multiple collections as command line arguments as shown above or use a
|
||||
requirements file in the format documented with :ref:`collection_requirements_file`.
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
ansible-galaxy collection download -r requirements.yml
|
||||
|
||||
You can also download a source collection directory. The collection is built with the mandatory ``galaxy.yml`` file.
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
ansible-galaxy collection download /path/to/collection
|
||||
|
||||
ansible-galaxy collection download git+file:///path/to/collection/.git
|
||||
|
||||
You can download multiple source collections from a single namespace by providing the path to the namespace.
|
||||
|
||||
.. code-block:: text
|
||||
|
||||
ns/
|
||||
├── collection1/
|
||||
│ ├── galaxy.yml
|
||||
│ └── plugins/
|
||||
└── collection2/
|
||||
├── galaxy.yml
|
||||
└── plugins/
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
ansible-galaxy collection install /path/to/ns
|
||||
|
||||
All the collections are downloaded by default to the ``./collections`` folder but you can use ``-p`` or
|
||||
``--download-path`` to specify another path:
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
ansible-galaxy collection download my_namespace.my_collection -p ~/offline-collections
|
||||
|
||||
Once you have downloaded the collections, the folder contains the collections specified, their dependencies, and a
|
||||
``requirements.yml`` file. You can use this folder as is with ``ansible-galaxy collection install`` to install the
|
||||
collections on a host without access to a Galaxy server.
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
# This must be run from the folder that contains the offline collections and requirements.yml file downloaded
|
||||
# by the internet-connected host
|
||||
cd ~/offline-collections
|
||||
ansible-galaxy collection install -r requirements.yml
|
||||
@ -1,6 +0,0 @@
|
||||
.. _index_collections:
|
||||
|
||||
Collections index
|
||||
=================
|
||||
|
||||
You can find an index of collections at :ref:`list_of_collections`.
|
||||
@ -1,126 +0,0 @@
|
||||
.. _collections_installing:
|
||||
|
||||
Installing collections
|
||||
======================
|
||||
|
||||
.. note::
|
||||
|
||||
If you install a collection manually as described in this paragraph, the collection will not be upgraded automatically when you upgrade the ``ansible`` package or ``ansible-core``.
|
||||
|
||||
Installing collections with ``ansible-galaxy``
|
||||
----------------------------------------------
|
||||
|
||||
.. include:: ../shared_snippets/installing_collections.txt
|
||||
|
||||
.. _installing_signed_collections:
|
||||
|
||||
Installing collections with signature verification
|
||||
---------------------------------------------------
|
||||
|
||||
If a collection has been signed by a :term:`distribution server`, the server will provide ASCII armored, detached signatures to verify the authenticity of the ``MANIFEST.json`` before using it to verify the collection's contents. This option is not available on all distribution servers. See :ref:`distributing_collections` for a table listing which servers support collection signing.
|
||||
|
||||
To use signature verification for signed collections:
|
||||
|
||||
1. :ref:`Configured a GnuPG keyring <galaxy_gpg_keyring>` for ``ansible-galaxy``, or provide the path to the keyring with the ``--keyring`` option when you install the signed collection.
|
||||
|
||||
|
||||
2. Import the public key from the distribution server into that keyring.
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
gpg --import --no-default-keyring --keyring ~/.ansible/pubring.kbx my-public-key.asc
|
||||
|
||||
|
||||
3. Verify the signature when you install the collection.
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
ansible-galaxy collection install my_namespace.my_collection --keyring ~/.ansible/pubring.kbx
|
||||
|
||||
The ``--keyring`` option is not necessary if you have :ref:`configured a GnuPG keyring <galaxy_gpg_keyring>`.
|
||||
|
||||
4. Optionally, verify the signature at any point after installation to prove the collection has not been tampered with. See :ref:`verify_signed_collections` for details.
|
||||
|
||||
|
||||
You can also include signatures in addition to those provided by the distribution server. Use the ``--signature`` option to verify the collection's ``MANIFEST.json`` with these additional signatures. Supplemental signatures should be provided as URIs.
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
ansible-galaxy collection install my_namespace.my_collection --signature https://examplehost.com/detached_signature.asc --keyring ~/.ansible/pubring.kbx
|
||||
|
||||
GnuPG verification only occurs for collections installed from a distribution server. User-provided signatures are not used to verify collections installed from git repositories, source directories, or URLs/paths to tar.gz files.
|
||||
|
||||
You can also include additional signatures in the collection ``requirements.yml`` file under the ``signatures`` key.
|
||||
|
||||
.. code-block:: yaml
|
||||
|
||||
# requirements.yml
|
||||
collections:
|
||||
- name: ns.coll
|
||||
version: 1.0.0
|
||||
signatures:
|
||||
- https://examplehost.com/detached_signature.asc
|
||||
- file:///path/to/local/detached_signature.asc
|
||||
|
||||
See :ref:`collection requirements file <collection_requirements_file>` for details on how to install collections with this file.
|
||||
|
||||
By default, verification is considered successful if a minimum of 1 signature successfully verifies the collection. The number of required signatures can be configured with ``--required-valid-signature-count`` or :ref:`GALAXY_REQUIRED_VALID_SIGNATURE_COUNT`. All signatures can be required by setting the option to ``all``. To fail signature verification if no valid signatures are found, prepend the value with ``+``, such as ``+all`` or ``+1``.
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
export ANSIBLE_GALAXY_GPG_KEYRING=~/.ansible/pubring.kbx
|
||||
export ANSIBLE_GALAXY_REQUIRED_VALID_SIGNATURE_COUNT=2
|
||||
ansible-galaxy collection install my_namespace.my_collection --signature https://examplehost.com/detached_signature.asc --signature file:///path/to/local/detached_signature.asc
|
||||
|
||||
Certain GnuPG errors can be ignored with ``--ignore-signature-status-code`` or :ref:`GALAXY_REQUIRED_VALID_SIGNATURE_COUNT`. :ref:`GALAXY_REQUIRED_VALID_SIGNATURE_COUNT` should be a list, and ``--ignore-signature-status-code`` can be provided multiple times to ignore multiple additional error status codes.
|
||||
|
||||
This example requires any signatures provided by the distribution server to verify the collection except if they fail due to NO_PUBKEY:
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
export ANSIBLE_GALAXY_GPG_KEYRING=~/.ansible/pubring.kbx
|
||||
export ANSIBLE_GALAXY_REQUIRED_VALID_SIGNATURE_COUNT=all
|
||||
ansible-galaxy collection install my_namespace.my_collection --ignore-signature-status-code NO_PUBKEY
|
||||
|
||||
If verification fails for the example above, only errors other than NO_PUBKEY will be displayed.
|
||||
|
||||
If verification is unsuccessful, the collection will not be installed. GnuPG signature verification can be disabled with ``--disable-gpg-verify`` or by configuring :ref:`GALAXY_DISABLE_GPG_VERIFY`.
|
||||
|
||||
|
||||
.. _collections_older_version:
|
||||
|
||||
Installing an older version of a collection
|
||||
-------------------------------------------
|
||||
|
||||
.. include:: ../shared_snippets/installing_older_collection.txt
|
||||
|
||||
.. _collection_requirements_file:
|
||||
|
||||
Install multiple collections with a requirements file
|
||||
-----------------------------------------------------
|
||||
|
||||
.. include:: ../shared_snippets/installing_multiple_collections.txt
|
||||
|
||||
.. _collection_offline_download:
|
||||
|
||||
Downloading a collection for offline use
|
||||
-----------------------------------------
|
||||
|
||||
.. include:: ../shared_snippets/download_tarball_collections.txt
|
||||
|
||||
Installing a collection from source files
|
||||
-----------------------------------------
|
||||
|
||||
.. include:: ../shared_snippets/installing_collections_file.rst
|
||||
|
||||
Installing a collection from a git repository
|
||||
---------------------------------------------
|
||||
|
||||
.. include:: ../shared_snippets/installing_collections_git_repo.txt
|
||||
|
||||
.. _galaxy_server_config:
|
||||
|
||||
Configuring the ``ansible-galaxy`` client
|
||||
------------------------------------------
|
||||
|
||||
.. include:: ../shared_snippets/galaxy_server_list.txt
|
||||
@ -1,74 +0,0 @@
|
||||
.. _collections_listing:
|
||||
|
||||
Listing collections
|
||||
===================
|
||||
|
||||
To list installed collections, run ``ansible-galaxy collection list``. This shows all of the installed collections found in the configured collections search paths. It will also show collections under development which contain a galaxy.yml file instead of a MANIFEST.json. The path where the collections are located are displayed as well as version information. If no version information is available, a ``*`` is displayed for the version number.
|
||||
|
||||
.. code-block:: shell
|
||||
|
||||
# /home/astark/.ansible/collections/ansible_collections
|
||||
Collection Version
|
||||
-------------------------- -------
|
||||
cisco.aci 0.0.5
|
||||
cisco.mso 0.0.4
|
||||
sandwiches.ham *
|
||||
splunk.es 0.0.5
|
||||
|
||||
# /usr/share/ansible/collections/ansible_collections
|
||||
Collection Version
|
||||
----------------- -------
|
||||
fortinet.fortios 1.0.6
|
||||
pureport.pureport 0.0.8
|
||||
sensu.sensu_go 1.3.0
|
||||
|
||||
Run with ``-vvv`` to display more detailed information.
|
||||
You may see additional collections here that were added as dependencies of your installed collections. Only use collections in your playbooks that you have directly installed.
|
||||
|
||||
To list a specific collection, pass a valid fully qualified collection name (FQCN) to the command ``ansible-galaxy collection list``. All instances of the collection will be listed.
|
||||
|
||||
.. code-block:: shell
|
||||
|
||||
> ansible-galaxy collection list fortinet.fortios
|
||||
|
||||
# /home/astark/.ansible/collections/ansible_collections
|
||||
Collection Version
|
||||
---------------- -------
|
||||
fortinet.fortios 1.0.1
|
||||
|
||||
# /usr/share/ansible/collections/ansible_collections
|
||||
Collection Version
|
||||
---------------- -------
|
||||
fortinet.fortios 1.0.6
|
||||
|
||||
To search other paths for collections, use the ``-p`` option. Specify multiple search paths by separating them with a ``:``. The list of paths specified on the command line will be added to the beginning of the configured collections search paths.
|
||||
|
||||
.. code-block:: shell
|
||||
|
||||
> ansible-galaxy collection list -p '/opt/ansible/collections:/etc/ansible/collections'
|
||||
|
||||
# /opt/ansible/collections/ansible_collections
|
||||
Collection Version
|
||||
--------------- -------
|
||||
sandwiches.club 1.7.2
|
||||
|
||||
# /etc/ansible/collections/ansible_collections
|
||||
Collection Version
|
||||
-------------- -------
|
||||
sandwiches.pbj 1.2.0
|
||||
|
||||
# /home/astark/.ansible/collections/ansible_collections
|
||||
Collection Version
|
||||
-------------------------- -------
|
||||
cisco.aci 0.0.5
|
||||
cisco.mso 0.0.4
|
||||
fortinet.fortios 1.0.1
|
||||
sandwiches.ham *
|
||||
splunk.es 0.0.5
|
||||
|
||||
# /usr/share/ansible/collections/ansible_collections
|
||||
Collection Version
|
||||
----------------- -------
|
||||
fortinet.fortios 1.0.6
|
||||
pureport.pureport 0.0.8
|
||||
sensu.sensu_go 1.3.0
|
||||
@ -1,119 +0,0 @@
|
||||
.. _using_collections:
|
||||
.. _collections_using_playbook:
|
||||
|
||||
Using collections in a playbook
|
||||
===============================
|
||||
|
||||
Once installed, you can reference a collection content by its fully qualified collection name (FQCN):
|
||||
|
||||
.. code-block:: yaml
|
||||
|
||||
- hosts: all
|
||||
tasks:
|
||||
- my_namespace.my_collection.mymodule:
|
||||
option1: value
|
||||
|
||||
This works for roles or any type of plugin distributed within the collection:
|
||||
|
||||
.. code-block:: yaml
|
||||
|
||||
- hosts: all
|
||||
tasks:
|
||||
- import_role:
|
||||
name: my_namespace.my_collection.role1
|
||||
|
||||
- my_namespace.mycollection.mymodule:
|
||||
option1: value
|
||||
|
||||
- debug:
|
||||
msg: '{{ lookup("my_namespace.my_collection.lookup1", 'param1')| my_namespace.my_collection.filter1 }}'
|
||||
|
||||
Simplifying module names with the ``collections`` keyword
|
||||
---------------------------------------------------------
|
||||
|
||||
The ``collections`` keyword lets you define a list of collections that your role or playbook should search for unqualified module and action names. So you can use the ``collections`` keyword, then simply refer to modules and action plugins by their short-form names throughout that role or playbook.
|
||||
|
||||
.. warning::
|
||||
If your playbook uses both the ``collections`` keyword and one or more roles, the roles do not inherit the collections set by the playbook. This is one of the reasons we recommend you always use FQCN. See below for roles details.
|
||||
|
||||
Using ``collections`` in roles
|
||||
------------------------------
|
||||
|
||||
Within a role, you can control which collections Ansible searches for the tasks inside the role using the ``collections`` keyword in the role's ``meta/main.yml``. Ansible will use the collections list defined inside the role even if the playbook that calls the role defines different collections in a separate ``collections`` keyword entry. Roles defined inside a collection always implicitly search their own collection first, so you don't need to use the ``collections`` keyword to access modules, actions, or other roles contained in the same collection.
|
||||
|
||||
.. code-block:: yaml
|
||||
|
||||
# myrole/meta/main.yml
|
||||
collections:
|
||||
- my_namespace.first_collection
|
||||
- my_namespace.second_collection
|
||||
- other_namespace.other_collection
|
||||
|
||||
Using ``collections`` in playbooks
|
||||
----------------------------------
|
||||
|
||||
In a playbook, you can control the collections Ansible searches for modules and action plugins to execute. However, any roles you call in your playbook define their own collections search order; they do not inherit the calling playbook's settings. This is true even if the role does not define its own ``collections`` keyword.
|
||||
|
||||
.. code-block:: yaml
|
||||
|
||||
- hosts: all
|
||||
collections:
|
||||
- my_namespace.my_collection
|
||||
|
||||
tasks:
|
||||
- import_role:
|
||||
name: role1
|
||||
|
||||
- mymodule:
|
||||
option1: value
|
||||
|
||||
- debug:
|
||||
msg: '{{ lookup("my_namespace.my_collection.lookup1", "param1")| my_namespace.my_collection.filter1 }}'
|
||||
|
||||
The ``collections`` keyword merely creates an ordered 'search path' for non-namespaced plugin and role references. It does not install content or otherwise change Ansible's behavior around the loading of plugins or roles. Note that an FQCN is still required for non-action or module plugins (for example, lookups, filters, tests).
|
||||
|
||||
When using the ``collections`` keyword, it is not necessary to add in ``ansible.builtin`` as part of the search list. When left omitted, the following content is available by default:
|
||||
|
||||
1. Standard ansible modules and plugins available through ``ansible-base``/``ansible-core``
|
||||
|
||||
2. Support for older 3rd party plugin paths
|
||||
|
||||
In general, it is preferable to use a module or plugin's FQCN over the ``collections`` keyword and the short name for all content in ``ansible-core``
|
||||
|
||||
Using a playbook from a collection
|
||||
----------------------------------
|
||||
|
||||
.. versionadded:: 2.11
|
||||
|
||||
You can also distribute playbooks in your collection and invoke them using the same semantics you use for plugins:
|
||||
|
||||
.. code-block:: shell
|
||||
|
||||
ansible-playbook my_namespace.my_collection.playbook1 -i ./myinventory
|
||||
|
||||
From inside a playbook:
|
||||
|
||||
.. code-block:: yaml
|
||||
|
||||
- import_playbook: my_namespace.my_collection.playbookX
|
||||
|
||||
|
||||
A few recommendations when creating such playbooks, ``hosts:`` should be generic or at least have a variable input.
|
||||
|
||||
.. code-block:: yaml
|
||||
|
||||
- hosts: all # Use --limit or customized inventory to restrict hosts targeted
|
||||
|
||||
- hosts: localhost # For things you want to restrict to the controller
|
||||
|
||||
- hosts: '{{target|default("webservers")}}' # Assumes inventory provides a 'webservers' group, but can also use ``-e 'target=host1,host2'``
|
||||
|
||||
|
||||
This will have an implied entry in the ``collections:`` keyword of ``my_namespace.my_collection`` just as with roles.
|
||||
|
||||
.. note::
|
||||
* Playbook names, like other collection resources, have a restricted set of valid characters.
|
||||
Names can contain only lowercase alphanumeric characters, plus _ and must start with an alpha character. The dash ``-`` character is not valid for playbook names in collections.
|
||||
Playbooks whose names contain invalid characters are not addressable: this is a limitation of the Python importer that is used to load collection resources.
|
||||
|
||||
* Playbooks in collections do not support 'adjacent' plugins, all plugins must be in the collection specific directories.
|
||||
@ -1,80 +0,0 @@
|
||||
.. _collections_verifying:
|
||||
|
||||
Verifying collections
|
||||
=====================
|
||||
|
||||
Verifying collections with ``ansible-galaxy``
|
||||
---------------------------------------------
|
||||
|
||||
Once installed, you can verify that the content of the installed collection matches the content of the collection on the server. This feature expects that the collection is installed in one of the configured collection paths and that the collection exists on one of the configured galaxy servers.
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
ansible-galaxy collection verify my_namespace.my_collection
|
||||
|
||||
The output of the ``ansible-galaxy collection verify`` command is quiet if it is successful. If a collection has been modified, the altered files are listed under the collection name.
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
ansible-galaxy collection verify my_namespace.my_collection
|
||||
Collection my_namespace.my_collection contains modified content in the following files:
|
||||
my_namespace.my_collection
|
||||
plugins/inventory/my_inventory.py
|
||||
plugins/modules/my_module.py
|
||||
|
||||
You can use the ``-vvv`` flag to display additional information, such as the version and path of the installed collection, the URL of the remote collection used for validation, and successful verification output.
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
ansible-galaxy collection verify my_namespace.my_collection -vvv
|
||||
...
|
||||
Verifying 'my_namespace.my_collection:1.0.0'.
|
||||
Installed collection found at '/path/to/ansible_collections/my_namespace/my_collection/'
|
||||
Remote collection found at 'https://galaxy.ansible.com/download/my_namespace-my_collection-1.0.0.tar.gz'
|
||||
Successfully verified that checksums for 'my_namespace.my_collection:1.0.0' match the remote collection
|
||||
|
||||
If you have a pre-release or non-latest version of a collection installed you should include the specific version to verify. If the version is omitted, the installed collection is verified against the latest version available on the server.
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
ansible-galaxy collection verify my_namespace.my_collection:1.0.0
|
||||
|
||||
In addition to the ``namespace.collection_name:version`` format, you can provide the collections to verify in a ``requirements.yml`` file. Dependencies listed in ``requirements.yml`` are not included in the verify process and should be verified separately.
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
ansible-galaxy collection verify -r requirements.yml
|
||||
|
||||
Verifying against ``tar.gz`` files is not supported. If your ``requirements.yml`` contains paths to tar files or URLs for installation, you can use the ``--ignore-errors`` flag to ensure that all collections using the ``namespace.name`` format in the file are processed.
|
||||
|
||||
.. _verify_signed_collections:
|
||||
|
||||
Verifying signed collections
|
||||
-----------------------------
|
||||
|
||||
If a collection has been signed by a :term:`distribution server`, the server will provide ASCII armored, detached signatures to verify the authenticity of the MANIFEST.json before using it to verify the collection's contents. This option is not available on all distribution servers. See :ref:`distributing_collections` for a table listing which servers support collection signing. See :ref:`installing_signed_collections` for how to verify a signed collection when you install it.
|
||||
|
||||
To verify a signed installed collection:
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
ansible-galaxy collection verify my_namespace.my_collection --keyring ~/.ansible/pubring.kbx
|
||||
|
||||
|
||||
Use the ``--signature`` option to verify collection name(s) provided on the CLI with an additional signature. This option can be used multiple times to provide multiple signatures.
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
ansible-galaxy collection verify my_namespace.my_collection --signature https://examplehost.com/detached_signature.asc --signature file:///path/to/local/detached_signature.asc --keyring ~/.ansible/pubring.kbx
|
||||
|
||||
Optionally, you can verify a collection signature with a ``requirements.yml`` file.
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
ansible-galaxy collection verify -r requirements.yml --keyring ~/.ansible/pubring.kbx
|
||||
|
||||
When a collection is installed from a distribution server, the signatures provided by the server to verify the collection's authenticity are saved alongside the installed collections. This data is used to verify the internal consistency of the collection without querying the distribution server again when the ``--offline`` option is provided.
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
ansible-galaxy collection verify my_namespace.my_collection --offline --keyring ~/.ansible/pubring.kbx
|
||||
@ -1,27 +0,0 @@
|
||||
.. _collections_index:
|
||||
.. _collections:
|
||||
|
||||
#########################
|
||||
Using Ansible collections
|
||||
#########################
|
||||
|
||||
.. note::
|
||||
|
||||
**Making Open Source More Inclusive**
|
||||
|
||||
Red Hat is committed to replacing problematic language in our code, documentation, and web properties. We are beginning with these four terms: master, slave, blacklist, and whitelist. We ask that you open an issue or pull request if you come upon a term that we have missed. For more details, see `our CTO Chris Wright's message <https://www.redhat.com/en/blog/making-open-source-more-inclusive-eradicating-problematic-language>`_.
|
||||
|
||||
Welcome to the Ansible guide for working with collections.
|
||||
|
||||
Collections are a distribution format for Ansible content that can include playbooks, roles, modules, and plugins.
|
||||
You can install and use collections through a distribution server, such as Ansible Galaxy, or a Pulp 3 Galaxy server.
|
||||
|
||||
.. toctree::
|
||||
:maxdepth: 2
|
||||
|
||||
collections_installing
|
||||
collections_downloading
|
||||
collections_listing
|
||||
collections_verifying
|
||||
collections_using_playbooks
|
||||
collections_index
|
||||
@ -1,33 +0,0 @@
|
||||
.. _cheatsheet:
|
||||
|
||||
**********************
|
||||
Ansible CLI cheatsheet
|
||||
**********************
|
||||
|
||||
This page shows one or more examples of each Ansible command line utility with some common flags added and a link to the full documentation for the command.
|
||||
This page offers a quick reminder of some common use cases only - it may be out of date or incomplete or both.
|
||||
For canonical documentation, follow the links to the CLI pages.
|
||||
|
||||
.. contents::
|
||||
:local:
|
||||
|
||||
ansible-playbook
|
||||
================
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
ansible-playbook -i /path/to/my_inventory_file -u my_connection_user -k -f 3 -T 30 -t my_tag -m /path/to/my_modules -b -K my_playbook.yml
|
||||
|
||||
Loads ``my_playbook.yml`` from the current working directory and:
|
||||
- ``-i`` - uses ``my_inventory_file`` in the path provided for :ref:`inventory <intro_inventory>` to match the :ref:`pattern <intro_patterns>`.
|
||||
- ``-u`` - connects :ref:`over SSH <connections>` as ``my_connection_user``.
|
||||
- ``-k`` - asks for password which is then provided to SSH authentication.
|
||||
- ``-f`` - allocates 3 :ref:`forks <playbooks_strategies>`.
|
||||
- ``-T`` - sets a 30-second timeout.
|
||||
- ``-t`` - runs only tasks marked with the :ref:`tag <tags>` ``my_tag``.
|
||||
- ``-m`` - loads :ref:`local modules <developing_locally>` from ``/path/to/my/modules``.
|
||||
- ``-b`` - executes with elevated privileges (uses :ref:`become <become>`).
|
||||
- ``-K`` - prompts the user for the become password.
|
||||
|
||||
See :ref:`ansible-playbook` for detailed documentation.
|
||||
|
||||
@ -1,23 +0,0 @@
|
||||
.. _command_line_tools:
|
||||
|
||||
Working with command line tools
|
||||
===============================
|
||||
|
||||
Most users are familiar with `ansible` and `ansible-playbook`, but those are not the only utilities Ansible provides.
|
||||
Below is a complete list of Ansible utilities. Each page contains a description of the utility and a listing of supported parameters.
|
||||
|
||||
.. note::
|
||||
You should not run most Ansible CLI tools in parallel against the same targets.
|
||||
|
||||
.. toctree::
|
||||
:maxdepth: 1
|
||||
|
||||
../cli/ansible.rst
|
||||
../cli/ansible-config.rst
|
||||
../cli/ansible-console.rst
|
||||
../cli/ansible-doc.rst
|
||||
../cli/ansible-galaxy.rst
|
||||
../cli/ansible-inventory.rst
|
||||
../cli/ansible-playbook.rst
|
||||
../cli/ansible-pull.rst
|
||||
../cli/ansible-vault.rst
|
||||
@ -1,21 +0,0 @@
|
||||
.. _command_guide_index:
|
||||
|
||||
################################
|
||||
Using Ansible command line tools
|
||||
################################
|
||||
|
||||
.. note::
|
||||
|
||||
**Making Open Source More Inclusive**
|
||||
|
||||
Red Hat is committed to replacing problematic language in our code, documentation, and web properties. We are beginning with these four terms: master, slave, blacklist, and whitelist. We ask that you open an issue or pull request if you come upon a term that we have missed. For more details, see `our CTO Chris Wright's message <https://www.redhat.com/en/blog/making-open-source-more-inclusive-eradicating-problematic-language>`_.
|
||||
|
||||
Welcome to the guide for using Ansible command line tools.
|
||||
Ansible provides ad hoc commands and several utilities for performing various operations and automation tasks.
|
||||
|
||||
.. toctree::
|
||||
:maxdepth: 2
|
||||
|
||||
intro_adhoc
|
||||
command_line_tools
|
||||
cheatsheet
|
||||
@ -1,220 +0,0 @@
|
||||
.. _intro_adhoc:
|
||||
|
||||
*******************************
|
||||
Introduction to ad hoc commands
|
||||
*******************************
|
||||
|
||||
An Ansible ad hoc command uses the `/usr/bin/ansible` command-line tool to automate a single task on one or more managed nodes.
|
||||
ad hoc commands are quick and easy, but they are not reusable.
|
||||
So why learn about ad hoc commands?
|
||||
ad hoc commands demonstrate the simplicity and power of Ansible.
|
||||
The concepts you learn here will port over directly to the playbook language.
|
||||
Before reading and executing these examples, please read :ref:`intro_inventory`.
|
||||
|
||||
.. contents::
|
||||
:local:
|
||||
|
||||
Why use ad hoc commands?
|
||||
========================
|
||||
|
||||
ad hoc commands are great for tasks you repeat rarely. For example, if you want to power off all the machines in your lab for Christmas vacation, you could execute a quick one-liner in Ansible without writing a playbook. An ad hoc command looks like this:
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
$ ansible [pattern] -m [module] -a "[module options]"
|
||||
|
||||
The ``-a`` option accepts options either through the ``key=value`` syntax or a JSON string starting with ``{`` and ending with ``}`` for more complex option structure.
|
||||
You can learn more about :ref:`patterns<intro_patterns>` and :ref:`modules<working_with_modules>` on other pages.
|
||||
|
||||
Use cases for ad hoc tasks
|
||||
==========================
|
||||
|
||||
ad hoc tasks can be used to reboot servers, copy files, manage packages and users, and much more. You can use any Ansible module in an ad hoc task. ad hoc tasks, like playbooks, use a declarative model,
|
||||
calculating and executing the actions required to reach a specified final state. They
|
||||
achieve a form of idempotence by checking the current state before they begin and doing nothing unless the current state is different from the specified final state.
|
||||
|
||||
Rebooting servers
|
||||
-----------------
|
||||
|
||||
The default module for the ``ansible`` command-line utility is the :ref:`ansible.builtin.command module<command_module>`. You can use an ad hoc task to call the command module and reboot all web servers in Atlanta, 10 at a time. Before Ansible can do this, you must have all servers in Atlanta listed in a group called [atlanta] in your inventory, and you must have working SSH credentials for each machine in that group. To reboot all the servers in the [atlanta] group:
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
$ ansible atlanta -a "/sbin/reboot"
|
||||
|
||||
By default Ansible uses only 5 simultaneous processes. If you have more hosts than the value set for the fork count, Ansible will talk to them, but it will take a little longer. To reboot the [atlanta] servers with 10 parallel forks:
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
$ ansible atlanta -a "/sbin/reboot" -f 10
|
||||
|
||||
/usr/bin/ansible will default to running from your user account. To connect as a different user:
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
$ ansible atlanta -a "/sbin/reboot" -f 10 -u username
|
||||
|
||||
Rebooting probably requires privilege escalation. You can connect to the server as ``username`` and run the command as the ``root`` user by using the :ref:`become <become>` keyword:
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
$ ansible atlanta -a "/sbin/reboot" -f 10 -u username --become [--ask-become-pass]
|
||||
|
||||
If you add ``--ask-become-pass`` or ``-K``, Ansible prompts you for the password to use for privilege escalation (sudo/su/pfexec/doas/etc).
|
||||
|
||||
.. note::
|
||||
The :ref:`command module <command_module>` does not support extended shell syntax like piping and
|
||||
redirects (although shell variables will always work). If your command requires shell-specific
|
||||
syntax, use the `shell` module instead. Read more about the differences on the
|
||||
:ref:`working_with_modules` page.
|
||||
|
||||
So far all our examples have used the default 'command' module. To use a different module, pass ``-m`` for module name. For example, to use the :ref:`ansible.builtin.shell module <shell_module>`:
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
$ ansible raleigh -m ansible.builtin.shell -a 'echo $TERM'
|
||||
|
||||
When running any command with the Ansible *ad hoc* CLI (as opposed to
|
||||
:ref:`Playbooks <working_with_playbooks>`), pay particular attention to shell quoting rules, so
|
||||
the local shell retains the variable and passes it to Ansible.
|
||||
For example, using double rather than single quotes in the above example would
|
||||
evaluate the variable on the box you were on.
|
||||
|
||||
.. _file_transfer:
|
||||
|
||||
Managing files
|
||||
--------------
|
||||
|
||||
An ad hoc task can harness the power of Ansible and SCP to transfer many files to multiple machines in parallel. To transfer a file directly to all servers in the [atlanta] group:
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
$ ansible atlanta -m ansible.builtin.copy -a "src=/etc/hosts dest=/tmp/hosts"
|
||||
|
||||
If you plan to repeat a task like this, use the :ref:`ansible.builtin.template<template_module>` module in a playbook.
|
||||
|
||||
The :ref:`ansible.builtin.file<file_module>` module allows changing ownership and permissions on files. These
|
||||
same options can be passed directly to the ``copy`` module as well:
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
$ ansible webservers -m ansible.builtin.file -a "dest=/srv/foo/a.txt mode=600"
|
||||
$ ansible webservers -m ansible.builtin.file -a "dest=/srv/foo/b.txt mode=600 owner=mdehaan group=mdehaan"
|
||||
|
||||
The ``file`` module can also create directories, similar to ``mkdir -p``:
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
$ ansible webservers -m ansible.builtin.file -a "dest=/path/to/c mode=755 owner=mdehaan group=mdehaan state=directory"
|
||||
|
||||
As well as delete directories (recursively) and delete files:
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
$ ansible webservers -m ansible.builtin.file -a "dest=/path/to/c state=absent"
|
||||
|
||||
.. _managing_packages:
|
||||
|
||||
Managing packages
|
||||
-----------------
|
||||
|
||||
You might also use an ad hoc task to install, update, or remove packages on managed nodes using a package management module such as ``yum``. Package management modules support common functions to install, remove, and generally manage packages. Some specific functions for a package manager might not be present in the Ansible module since they are not part of general package management.
|
||||
|
||||
To ensure a package is installed without updating it:
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
$ ansible webservers -m ansible.builtin.yum -a "name=acme state=present"
|
||||
|
||||
To ensure a specific version of a package is installed:
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
$ ansible webservers -m ansible.builtin.yum -a "name=acme-1.5 state=present"
|
||||
|
||||
To ensure a package is at the latest version:
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
$ ansible webservers -m ansible.builtin.yum -a "name=acme state=latest"
|
||||
|
||||
To ensure a package is not installed:
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
$ ansible webservers -m ansible.builtin.yum -a "name=acme state=absent"
|
||||
|
||||
Ansible has modules for managing packages under many platforms. If there is no module for your package manager, you can install packages using the command module or create a module for your package manager.
|
||||
|
||||
.. _users_and_groups:
|
||||
|
||||
Managing users and groups
|
||||
-------------------------
|
||||
|
||||
You can create, manage, and remove user accounts on your managed nodes with ad hoc tasks:
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
$ ansible all -m ansible.builtin.user -a "name=foo password=<crypted password here>"
|
||||
|
||||
$ ansible all -m ansible.builtin.user -a "name=foo state=absent"
|
||||
|
||||
See the :ref:`ansible.builtin.user <user_module>` module documentation for details on all of the available options, including
|
||||
how to manipulate groups and group membership.
|
||||
|
||||
.. _managing_services:
|
||||
|
||||
Managing services
|
||||
-----------------
|
||||
|
||||
Ensure a service is started on all webservers:
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
$ ansible webservers -m ansible.builtin.service -a "name=httpd state=started"
|
||||
|
||||
Alternatively, restart a service on all webservers:
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
$ ansible webservers -m ansible.builtin.service -a "name=httpd state=restarted"
|
||||
|
||||
Ensure a service is stopped:
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
$ ansible webservers -m ansible.builtin.service -a "name=httpd state=stopped"
|
||||
|
||||
.. _gathering_facts:
|
||||
|
||||
Gathering facts
|
||||
---------------
|
||||
|
||||
Facts represent discovered variables about a system. You can use facts to implement conditional execution of tasks but also just to get ad hoc information about your systems. To see all facts:
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
$ ansible all -m ansible.builtin.setup
|
||||
|
||||
You can also filter this output to display only certain facts, see the :ref:`ansible.builtin.setup <setup_module>` module documentation for details.
|
||||
|
||||
Patterns and ad-hoc commands
|
||||
----------------------------
|
||||
|
||||
See the :ref:`patterns <intro_patterns>` documentation for details on all of the available options, including
|
||||
how to limit using patterns in ad-hoc commands.
|
||||
|
||||
Now that you understand the basic elements of Ansible execution, you are ready to learn to automate repetitive tasks using :ref:`Ansible Playbooks <playbooks_intro>`.
|
||||
|
||||
.. seealso::
|
||||
|
||||
:ref:`intro_configuration`
|
||||
All about the Ansible config file
|
||||
:ref:`list_of_collections`
|
||||
Browse existing collections, modules, and plugins
|
||||
:ref:`working_with_playbooks`
|
||||
Using Ansible for configuration management & deployment
|
||||
`Mailing List <https://groups.google.com/group/ansible-project>`_
|
||||
Questions? Help? Ideas? Stop by the list on Google Groups
|
||||
:ref:`communication_irc`
|
||||
How to join Ansible chat channels
|
||||
@ -1,14 +0,0 @@
|
||||
.. _advanced_community_guide:
|
||||
|
||||
**********************************************
|
||||
Advanced Contributor Guide
|
||||
**********************************************
|
||||
|
||||
This guide focuses on contributors who are committers, GitHub admins, or release managers.
|
||||
|
||||
.. toctree::
|
||||
:maxdepth: 1
|
||||
|
||||
committer_guidelines
|
||||
release_managers
|
||||
github_admins
|
||||
@ -1,145 +0,0 @@
|
||||
.. _code_of_conduct:
|
||||
|
||||
*************************
|
||||
Community Code of Conduct
|
||||
*************************
|
||||
|
||||
.. contents:: Topics
|
||||
|
||||
Every community can be strengthened by a diverse variety of viewpoints, insights,
|
||||
opinions, skillsets, and skill levels. However, with diversity comes the potential for
|
||||
disagreement and miscommunication. The purpose of this Code of Conduct is to ensure that
|
||||
disagreements and differences of opinion are conducted respectfully and on their own
|
||||
merits, without personal attacks or other behavior that might create an unsafe or
|
||||
unwelcoming environment.
|
||||
|
||||
These policies are not designed to be a comprehensive set of Things You Cannot Do. We ask
|
||||
that you treat your fellow community members with respect and courtesy, and in general,
|
||||
Don't Be A Jerk. This Code of Conduct is meant to be followed in spirit as much as in
|
||||
letter and is not exhaustive.
|
||||
|
||||
All Ansible events and participants therein are governed by this Code of Conduct and
|
||||
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
|
||||
contributions, public chat (Matrix, IRC), private correspondence, and public meetings.
|
||||
|
||||
Ansible community members are...
|
||||
|
||||
**Considerate**
|
||||
|
||||
Contributions of every kind have far-ranging consequences. Just as your work depends on
|
||||
the work of others, decisions you make surrounding your contributions to the Ansible
|
||||
community will affect your fellow community members. You are strongly encouraged to take
|
||||
those consequences into account while making decisions.
|
||||
|
||||
**Patient**
|
||||
|
||||
Asynchronous communication can come with its own frustrations, even in the most responsive
|
||||
of communities. Please remember that our community is largely built on volunteered time,
|
||||
and that questions, contributions, and requests for support may take some time to receive
|
||||
a response. Repeated "bumps" or "reminders" in rapid succession are not good displays of
|
||||
patience. Additionally, it is considered poor manners to ping a specific person with
|
||||
general questions. Pose your question to the community as a whole, and wait patiently for
|
||||
a response.
|
||||
|
||||
**Respectful**
|
||||
|
||||
Every community inevitably has disagreements, but remember that it is
|
||||
possible to disagree respectfully and courteously. Disagreements are never an excuse for
|
||||
rudeness, hostility, threatening behavior, abuse (verbal or physical), or personal attacks.
|
||||
|
||||
**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
|
||||
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,
|
||||
stalking, sustained disruption of activities, publishing the personal information of
|
||||
others without explicit permission to do so, unwanted physical contact, and unwelcome
|
||||
sexual attention are all strictly prohibited. Additionally, you are encouraged not to
|
||||
make assumptions about the background or identity of your fellow community members.
|
||||
|
||||
**Inquisitive**
|
||||
|
||||
The only stupid question is the one that does not get asked. We
|
||||
encourage our users to ask early and ask often. Rather than asking whether you can ask a
|
||||
question (the answer is always yes!), instead, simply ask your question. You are
|
||||
encouraged to provide as many specifics as possible. Code snippets in the form of Gists or
|
||||
other paste site links are almost always needed in order to get the most helpful answers.
|
||||
Refrain from pasting multiple lines of code directly into the chat channels - instead use
|
||||
gist.github.com or another paste site to provide code snippets.
|
||||
|
||||
**Helpful**
|
||||
|
||||
The Ansible community is committed to being a welcoming environment for all users,
|
||||
regardless of skill level. We were all beginners once upon a time, and our community
|
||||
cannot grow without an environment where new users feel safe and comfortable asking questions.
|
||||
It can become frustrating to answer the same questions repeatedly; however, community
|
||||
members are expected to remain courteous and helpful to all users equally, regardless of
|
||||
skill or knowledge level. Avoid providing responses that prioritize snideness and snark over
|
||||
useful information. At the same time, everyone is expected to read the provided
|
||||
documentation thoroughly. We are happy to answer questions, provide strategic guidance,
|
||||
and suggest effective workflows, but we are not here to do your job for you.
|
||||
|
||||
Anti-harassment policy
|
||||
======================
|
||||
|
||||
Harassment includes (but is not limited to) all of the following behaviors:
|
||||
|
||||
- Offensive comments related to gender (including gender expression and identity), age, sexual orientation, disability, physical appearance, body size, race, and religion
|
||||
- Derogatory terminology including words commonly known to be slurs
|
||||
- Posting sexualized images or imagery in public spaces
|
||||
- Deliberate intimidation
|
||||
- Stalking
|
||||
- Posting others' personal information without explicit permission
|
||||
- Sustained disruption of talks or other events
|
||||
- Inappropriate physical contact
|
||||
- Unwelcome sexual attention
|
||||
|
||||
Participants asked to stop any harassing behavior are expected to comply immediately.
|
||||
Sponsors are also subject to the anti-harassment policy. In particular, sponsors should
|
||||
not use sexualized images, activities, or other material. Meetup organizing staff and
|
||||
other volunteer organizers should not use sexualized attire or otherwise create a
|
||||
sexualized environment at community events.
|
||||
|
||||
In addition to the behaviors outlined above, continuing to behave a certain way after you
|
||||
have been asked to stop also constitutes harassment, even if that behavior is not
|
||||
specifically outlined in this policy. It is considerate and respectful to stop doing
|
||||
something after you have been asked to stop, and all community members are expected to
|
||||
comply with such requests immediately.
|
||||
|
||||
Policy violations
|
||||
=================
|
||||
|
||||
Instances of abusive, harassing, or otherwise unacceptable behavior may be reported by
|
||||
contacting `codeofconduct@ansible.com <mailto:codeofconduct@ansible.com>`_, to anyone with administrative power in community chat (Admins or Moderators on Matrix, ops on IRC), or to the local organizers of an event. Meetup
|
||||
organizers are encouraged to prominently display points of contact for reporting unacceptable
|
||||
behavior at local events.
|
||||
|
||||
If a participant engages in harassing behavior, the meetup organizers may take any action
|
||||
they deem appropriate. These actions may include but are not limited to warning the
|
||||
offender, expelling the offender from the event, and barring the offender from future
|
||||
community events.
|
||||
|
||||
Organizers will be happy to help participants contact security or local law enforcement,
|
||||
provide escorts to an alternate location, or otherwise assist those experiencing
|
||||
harassment to feel safe for the duration of the meetup. We value the safety and well-being
|
||||
of our community members and want everyone to feel welcome at our events, both online and
|
||||
offline.
|
||||
|
||||
We expect all participants, organizers, speakers, and attendees to follow these policies at
|
||||
all of our event venues and event-related social events.
|
||||
|
||||
The Ansible Community Code of Conduct is licensed under the Creative Commons
|
||||
Attribution-Share Alike 3.0 license. Our Code of Conduct was adapted from Codes of Conduct
|
||||
of other open source projects, including:
|
||||
|
||||
* Contributor Covenant
|
||||
* Elastic
|
||||
* The Fedora Project
|
||||
* OpenStack
|
||||
* Puppet Labs
|
||||
* Ubuntu
|
||||
Some files were not shown because too many files have changed in this diff Show More
Reference in New Issue
Block a user